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1 Scope 

The present document defines the network architecture and the reference configurations that are necessary for: 

• the delivery of telephone calls which originate in an Internet Protocol (IP) network and are delivered to Switched 
Circuit Networks (SCN); 

• the delivery of telephone calls which originate in SCNs and are delivered in an IP network; 

• the delivery of telephone calls which originate in SCNs, routed through a IP network and finally delivered to an 
SCN; and 

• the delivery of telephone calls which originate and terminate in IP networks. Such calls may be routed using an 
SCN. 

These four scenarios are part of TIPHON Release 2. 

The architecture includes provision of information and facilities which are incidental to the delivery of telephone calls 
described above. 

The present document builds upon the concepts embodied in the TIPHON Phase II Network Architecture and Reference 
Configurations [5] by considering the additional scenarios and the expansion of the IP network into a more appropriate 
network model. Annex B shows the relationship with the previous architecture. 

The present document is applicable to equipment performing the roles of terminal, and Gateway, and also to entities 
within the IP network that are necessary to support the four scenarios of TIPHON Release 2. Where the text indicates 
the status of a requirement (i.e. as strict command or prohibition, as authorizations leaving freedom or as a capability or 
possibility), this may modify the nature of a requirement within a referenced standard used to provide the capability. 



2 References 

The following documents contain provisions, which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[1] ITU-T Recommendation E.164 (1997): "The international public telecommunications numbering 

plan". 

[2] ETSI EN 300 189: "Private Integrated Services Network (PISN); Addressing [ISO/IEC 1 1571 

(1998), modified]". 

[3] ISO/IEC 1 1571: "Information technology — Telecommunications and information exchange 

between systems — Private Integrated Services Networks - Addressing". 

[4] ETSI TR 101 300: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON); Description of Technical Issues". 

[5] ETSI TS 101 313 (VO.4.2): "Telecommunications and Internet Protocol Harmonization Over 

Networks (TIPHON); Network architecture and reference configurations; Phase II: Scenario 1 + 
Scenario 2". 



ETSI 



9 



ETSI TS 101 314 V1.1.1 (2000-09) 



[6] 



ETSI TR 101 307: "Telecommunications and Internet Protocol Harmonization Over Networks 
(TIPHON); Requirements for service interoperability; Phase 2" 



17] 



ETSI TS 101 329-2: "Telecommunications and Internet Protocol Harmonisation over Networks 
(TIPHON); End to End Quality of Service in TIPHON Systems; Part 2: Definition of Quality of 
Service (QoS) Classes". 



3 



Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 
administrative domain: network controlled by a single operator 

gateway: endpoint on a network which provides for real time, two way communication between an IP based network 
and an Switched Circuit Network (SCN) 

information flow: defines a complete set of logical information exchanged between two functional entities 

interconnection function: functional entity connecting two networks having differing administrative policy such as 
Quality of Service (QoS) or addressing policy but employing the same signalling protocol, and transport technology, at 
the point of interconnect 

interface: common boundary between two communicating entities. One or more protocols may be implemented across 
an interface 

interworking function: function connecting two networks of different signalling and or transport technology 
IP network: managed transport network supporting IP 

IP telephony: this phrase is used as a shorthand to describe any telephony related service that is supported on IP 

NOTE: Such services may also be supported by other technologies. 

protocol: set of rules and formats which govern exchange of information across an interface between two functional 
entities for purposes of information transfer 

reference point: conceptual point at the conjunction of two non overlapping functions 

service provider network: network controlled by a Service Provider which offers service to other persons 

Switched Circuit Network (SCN): telecommunications network, e.g. Public Switched Telephone Network (PSTN), 
Integrated Services Digital Network (ISDN), and General System for Mobile communications (GSM), that uses circuit- 
switched technologies for the support of voice calls. The SCN may be a public network or a private network 

telephone call: two-way speech communication between two users by means of terminals connected via network 
infrastructure 

terminal: endpoint other than a gateway or a multipoint control unit 

TIPHON compliant system: system that complies with the mandatory requirements identified in the TIPHON 
requirements documents together with compliance to the parts of the TIPHON specifications in which these 
requirements are embodied 

ticket: a ticket is obtained through the registration session, when used in a call it provides the terminal/user with a 
means to show a valid registration exists 



ETSI 



10 



ETSI TS 101 314 V1.1.1 (2000-09) 



3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



BC 


Rearer Control 


BICC 


Rparpr TnHpnpnHpnt f^all f^nntrnl 

IJl.al Ll 1 1 1UI IJC 1 1U 1 1 1 V^Ull V-A' 1 1 L 1 VI 


CC 


Call Control 


DTMF 


Dual Tnnp TVTnlti Frpmipnfv 

l_V L I H 1 1 WllL' iVlLllLl 1 1 vU UV^llV^ V 


FG 


Pn npti onnl frroiinin o 

1 U11C LlVJlloJ VJlVJlllJllll; 


IN 


Tntpllitrpnt TMf*twnrk" 


IP 


Internet Protocol 


IPTN 


IP Telenhnnv lVptwnrk" 

11 1 l/llf IJ11VJ11 J 1 1 L/ L W Ul JV 


1WF 

1 VV 1 


111LC1 VV VI IS. 1 1 J ij, 1 UllV^LlVJll 


MC 


IVTpHia f^nntrnl 

IVltUla V^VJllLl VJ1 


MSC 


Message Sequence Charts 


NFG 

11 1 VJ 


Mptw/ovlr Pnnptionnl fTrniinintT 

1>CLWVJ1JV 1 UllV^LlVJlla.1 Vjl VJ UJJlllg 


OGFG 


Oriainntina HatPWAV Pnnptinnal Clrminina 

VJll^llltHlllg UdLCWdJ' 1 UllV^LlVJlla.1 VJ1 VJ UJJlllg 


OTFG 


Originating Terrninal Functional Grouping 


PCM 


Pulse Code Modulation 


PSTN 


Public Switched Telephony Network 


QoS 


Quality of Service 


SC 


Service Control 


SCN 


Switched Circuit Networks 


SCNIWF 


Switched circuit network inter-working function 


SDL 


Specification and Description Language 


SIP 


Session Initiation Protocol 


SSP 


Service Switching Point 


TGFG 


Terminating Gateway Functional Grouping 


TTFG 


Terminating Terminal Functional Grouping 



4 Introduction 

The network architecture and reference configurations contained in the present document are derived from examination 
of the capabilities required by [6] for the support of TIPHON Scenarios 0, 1, 2, 3 and 4 as identified in [4]. 

The present document demonstrates how the scenarios given in [4], may be expressed as a set of interconnected 
networks with associated Interconnecting Functions. From this model, the concepts of functional planes, Functional 
Groupings, and functional layers are developed. 

Where there is a requirement that an information flow needs to be exchanged between physical equipment, a reference 
point is defined. Where an information flow will only be internal to pieces of physical equipment, no reference point is 
defined. 

Finally Message Sequence Charts (MSC) and Specification and Description Language (SDL) diagrams are presented in 
the form of a generalized model. 



5 Networks 

TIPHON Scenarios 1, 2, 3 and 4 require interconnection of IP Telephony Networks (IPTN) and Switched Circuit 
Networks (SCN). For the purpose of the model, functionality can be distributed across a number of networks. 

Each network is part of only one administrative domain. When different administrative domains provide all functions 
needed to e.g. originate a call, these functions pertain to different networks. Each administrative domain may have its 
own policies on addressing, Quality of Service (QoS), etc. 

Each network may further be decomposed into functional groups, as shown in Clause 7. 
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5.1 Networks involved in registration 

Figure 1 shows the network types that may inter-operate during the registration of a user. 



Serving 
IPTN 




Intermediate 
IPTN 




Home 
IPTN 







Figure 1 : TIPHON generic network registration model 

The Home IPTN is the principle place where the user information is stored. The Home IPTN provides the functions 
required for registration and for subscriber related operations. 

The Serving IPTN provides the function required to register the user and to forward the registration towards the Home 
IPTN. 

The Intermediate IPTN provides the functions required to connect the Serving IPTN and the Home IPTN during the 
registration. The intermediate IPTN is only present when the Serving IPTN and the Home IPTN are not directly 
connected. 

An IPTN may act as both the Serving IPTN and the Home IPTN. 



5.2 Networks involved in calls 

Figure 2 shows the different types of networks that may inter-operate for calls in TIPHON compliant systems. A 
specific call may not involve all network types. Each network will include any required interconnecting and 
interworking functions. 
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Figure 2: TIPHON generic network call model 

The Originating IPTN contains a set of functions required for originating calls from an IP terminal device. 

The Originating SCN contains a set of functions required for originating calls from a SCN terminal device. 

The Intermediate IPTN contains a set of functions required for connecting calls between originating and terminating 
networks. This network may not be present for some calls but may be present several times in a call. 

The Intermediate SCN contains a set of functions required for connecting calls between originating and terminating 
networks. This network may not be present for some calls but may be present several times in a call. 

The Terminating IPTN contains a set of functions required for terminating calls to an IP terminal device. 

The Terminating SCN contains a set of functions required for terminating calls to a SCN terminal device. 
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The Home IPTN contains a set of functions required for subscription-related operations. 

An IPTN may act as any combination of an Originating IPTN, and/or a Home IPTN and/or a Terminating IPTN. 



Each of the networks in the TIPHON generic network model may be considered as comprising distinct groupings of 
functionality. Within a network, these functions interact to enable the policies and business objectives for that network 
to be achieved through exercising appropriate control of the resources within that network. 

In order to provide a structured analysis of the requirements, the concept of "functional planes" is used. Each functional 
plane contains a high level grouping of functionality. 

IPTNs can be considered to contain sets of similar functions and it is possible to consider these functions to be grouped 
as planes of common functionality. The IPTN can be separated into an IP Transport plane and an IP Telephony 
Application plane. 

Figure 3 identifies the following functional planes: 

• IP telephony application; 

• IP transport; 

• SCN; 

• Management. 



The IP Telephony Application plane makes use of capabilities provided by the other functional planes and it contains 
functions to support IP telephony. 

The IP Transport plane contains the functionality relating to the underlying packet transport and the functionality of 
servers in general use. The details of this functional plane are not considered further in the present document. 

The SCN plane contains the functionality relating to the SCN. The details of this functional plane are not considered 
further in the present document. 

The Management plane contains the functionality relating to network management. The details of this functional plane 
are not considered further in the present document. 



6 



Functional planes 




Figure 3: TIPHON Functional Planes 
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7 Functional groupings 

Functionality in the IP Telephony Application plane can be gathered into functional groups. 

7.1 Functional groupings involved in registration 

Figure 4 shows functional groupings for registration. 
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Figure 4: Overview of functional groupings involved in registration 

The Terminal Registration Functional Grouping represents the functionality of the registering terminal. 

The Serving Network Functional Grouping represents the functions required to enable the user to register and to use 
services. 

The Intermediate Functional Grouping connects the Serving Network Functional Group to the Home Network 
Functional Grouping. 

The Home Network Functional Grouping represents functionality relating to the user's profile and subscription. 

The Home Network Functional Grouping and the Serving Network Functional Grouping may reside in the same 
network or in different networks. 



7.2 Functional groupings involved in a call 

Figure 5 shows functional groupings for a call. 
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Figure 5: Overview of functional groupings involved in a call 

The Originating Terminal Functional Grouping represents the functionality of the calling terminal. 

The Originating Gateway Functional Grouping represents the functionality of the ingress gateway from an SCN. 

The Terminating Terminal Functional Grouping represents the functionality of the called terminal. 
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The Terminating Gateway Functional Grouping represents the functionality of the egress gateway to an SCN. 

The Network Functional Grouping represents all of the functionality of the IP network(s) in support of the call. Figure 5 
shows the case where the originating and terminating functional groupings are associated with a single "network". 
Where the originating and terminating functional groupings are associated with different networks, the Network 
Functional Grouping can be separated into an Originating Network Functional Grouping and a Terminating Network 
Functional Grouping (see figure 6). 
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Figure 6: Separation of Network Functional Groupings into originating and terminating Network 

Functional Groupings 

Figure 6 also includes Interconnecting Functional Groupings that provide functions, e.g. protocol conversions, policy 
enforcement, that enables the networks to communicate. 

NOTE 1 : In some implementations, there may be no need for an interconnection function between some networks, 
but it is necessary to include this functionality to develop a consistent model. 

Where there is an intermediate network between the Originating Network Functional Grouping and the Terminating 
Network Functional Grouping, the Network Functional Grouping can be further subdivided to include one or more 
Intermediate Network Functional Groupings (see figure 7). 
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Figure 7: Intermediate Network Functional Grouping 

As in figure 6, Interconnecting Functional Groupings are included to enable the networks to communicate. 
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Also, figure 7 includes an Intermediate Gateway Functional Grouping that provides communication with SCNs. 

NOTE 2: The figures do not consider mobility aspects. 
These functional groupings may be used to construct the four scenarios as follows: 

• for Scenario 1, the call is from an Originating Terminal Functional Grouping to a Terminating Gateway 
Functional Grouping; 

• for Scenario 2, the call is from an Originating Gateway Functional Grouping to a Terminating Terminal 
Functional Grouping; 

• for Scenario 3, the call is from an Originating Gateway Functional Grouping to a Terminating Gateway 
Functional Grouping; and 

• for Scenario 4, the call is from an Originating Terminal Functional Grouping to a Terminating Terminal 
Functional Grouping using a pair of Intermediate Gateway Functional Groupings enabling communication via 
anSCN. 



8 Functional decomposition of the IP telephony 
application plane 

The architecture for the IP telephony application plane consists of functional entities organized into functional layers. 
One functional layer builds upon functionality provided by another functional layer. Together they provide the 
telephony application. This grouping is useful for the understanding of the functionality involved but does not imply 
any physical implementation. There are information flows between the functional entities. Information flows may be: 

• between functional entities in the same functional layer; 

• between a functional entity in one functional layer and a functional entity in the next functional layer upwards; 
and 

• between a functional entity in one functional layer and a functional entity in the next functional layer 
downwards. 

A functional entity may have one or more of these types of information flow. 

There are information flows between functional entities in the IP Telephony Application plane and the other functional 
planes. 

Where it can be determined that there is a requirement for a physical interface between entities residing in separate 
pieces of physical equipment, a reference point will be defined. One reference point may encompass multiple distinctive 
information flows. 

A standardized protocol will be required to support information flows in cases where a reference point is defined. 



8.1 Introduction to the functional layers 

The TIPHON functional architecture has 5 functional layers: the service functional layer, the service control functional 
layer, the call control functional layer, the bearer control functional layer and the media functional layer. 

These functional layers are shown in figure 8. For simplicity only two functions are shown in each functional layer with 
all of the possible communication paths within the functional layer and to the adjacent functional layers. 
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Figure 8: Functional layers in the IP Telephony Application plane 

In the subsequent sub-clauses each of the functional layers is introduced. 

8.1 .1 The services functional layer 

The services functional layer shall support a range of services (e.g. authentication) provided internally to a service 
network or functional grouping, or provided by third parties either locally or remotely via other networks or functional 
groupings. 



This functional layer has the following functions. 



Service profile function 


Provides information required for registration and stores information received 
during registration. Provides on request information needed for call 
establishment. 




User profile function 


Holds information about the user 




Route function 


Provides address/number translation, number length determination and 
telephony routing capabilities. 



8.1 .2 The service control functional layer 

The service control functional layer shall contain functionality that is needed for the calls but may have a life span 
longer or shorter than the duration of the call (examples are terminal registration, call routing). The service control 
functional layer shall provide an interface to functions in the Services functional layer that may be provided internally 
to a service network, or provided by third parties either locally or remotely via other networks. 



This functional layer has the following functions. 



Service Control (SC) function 


Provides support for calls 


• Number portability 

• Called User location 

• Name to Name translation 

• Name to address translation 

• Call access authorization 


Provides a routable user name or address to the called user. 

Determines where the called user currently is within the service 
provider network. 

Converts a user name to a routable user name. 

Provides a routable address associated with the user name. 

Authorizes a call to proceed. 
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; Registration (terminal part) Function 


Registers a user at a terminal with a service provider. 




Registration (network part) Function 


Accepts registration of a user at a terminal. 



8.1 .3 The call control functional layer 



The call control functional layer shall maintain a call context. The call context allows the services offered by the 
Bearer Control functional layer to provide the connections and capabilities requested by the customer as permitted by 
the service provider. In order to achieve this control, the Call Control functional layer may request information from the 
Service Control functional layer. The Call Control functional layer sends and receives signalling to users and networks. 

This functional layer has the following functions. 



Call Control (CC) Function 



Maintains the call state and, if present, provides services that change the 
call state e.g. call hold, suspend, three way and conferencing. 
Communication with peer Call Control functions for the establishment 
and release of calls. 

Requests services from functions in the Service Control functional layer. 

Request determination of, allocation of, and release of, resources from 
Bearer Control functions. 



8.1 .4 The Bearer Control functional layer 

The Bearer Control functional layer manages the logical association between pairs of endpoints. Bearer control shall 
be responsible for mapping call topology to individual media flows (e.g. connect parties a, b and c together). These 
flows may be between any pair of media processing functions in the media functional layer. 



This layer has the following functional functions: 



Bearer Control (BC) Function 


Allows or disallows media streaming based on information from call 
control 


• Bearer negotiation 

• Media resource acquisition 


Negotiates with other Bearer Control functions. 
Communicates with the Media Control function to obtain media 
resources for the bearer. 



8.1 .5 The Media Control functional layer 

The Media Control functional layer shall be responsible for the properties of the individual media flows. In this 
functional layer media encoding is determined, Quality of Service (QoS) paths are reserved and firewalls are controlled 
in conjunction with the IP Transport plane. 

This functional layer has the following functions. 
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Media Control (MC) functions 


Provides IP transport addresses for media reception and 
transmission. 


• Circuit Network Media Termination 

• Media Processing 

• Media Resource Management 

• Packet Media Termination 

• IP transport signalling 


Termination of for example: all lower-functional layer circuit network 

hardware and protocols, including the method by which speech is 

placed on the wire, e.g. PCM a-law, PCM u-law, etc. 

Performs signal processing functions such as voice compression, 

network echo-cancellation, silence suppression, comfort noise 

generation, encryption, codec translation, fax conversion, media 

insertion (DTMF, messages) filtering and analogue modem 

conversion (for passing analogue modem signals "transparently" 

through the packet network). 

Allocates internal resources in the media plane 

Termination of all methods involved in putting media over the packet 

network. This includes transport protocols and framing. 

Reserves QoS paths and controls firewalls in the IP Transport plane. 



8.2 Examples 

This clause contains some examples describing the entities defined above and their inter-relationship. 

8.2.1 Bearer 

A bearer is instantiated for the purpose of media communication through co-operation of the Media Control functional 
layer and the IP Transport plane. 

Figure 9 shows how the media control in conjunction with the transport plane provides the call with a bearer (media and 
transport) and that BC control the properties of the bearer. 
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Figure 9: Bearer Control 
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8.2.2 End to end example 

In figure 10 an example is given of the functions of the functional layers. Note that for simplicity the Services 
functional layer is not shown in figure 10. 



2. Locate 
terminating 
network 



Originating 
Network 



Terminating 
Network 




1 . Setup voice 
and video call 
toB 



7. Send media 
to border 
entity 1 



Originati 
Terminal(A) 




3£. Setup a eall 
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3b. Setup bearer 
betwee/i border entities 

/ 2 and 3. 



terminating 
Terminal 



CC 



5. Do you want a 
voice call from A 



. Setup QoS 
path between 
border entities 1&2 




-n 



Border 
entityl 



Border entity 2 




8. Send media to 
border entity 4 



Terminating 
Terminal(B) 



Border entit 



o 

Border entity 4 



NOTE: Steps 3a and 3b may be initiated in parallel, but the completion of bearer establishment may occur prior to 
establishment of the call. 

Figure 10: Example of the functional layers and their communication with the IP Transport plane 



The figure 10 shows two terminals and two networks. Each network has its own transport network (the clouds at the 
bottom). In this example, the user at Originating terminal (A) requests a call to party B. (Note that the functional layers 
are also present in the terminals but this is not shown in the picture.) 

The originating network is asked to set up the call. As a result of the request for routing, the Call Control functional 
layer in the originating network is instructed to setup the call to the network in which the party B resides. The Call 
Control functional layers in both networks co-operate to establish this call, each communicating with its Service Control 
functional layer for authentication and call routing. 

The media communication is done through bearers. Within each network the Bearer Control functional layer co- 
operates with the appropriate terminal to establish the bearer properties. Between the networks the bearer entities 
communicate the inter-network bearer properties. 
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The Media Control functional layers in each network allocate the appropriate firewalls/edge routers in the IP Transport 
plane and establish a QoS channel between them. If media transcoding or other media transformation e.g. echo 
cancellation is necessary the Media Control functional layer performs it. 

8.2.3 Relationship between BC, MC and TR entities 

Figure 1 1 shows how one bearer may be constructed out of multiple concatenated media flows each with its own 
transport. One Bearer Control entity communicates with multiple entities in the Media Control functional layer. Media 
flows through each entity in the Media Control functional layer. For each flow the entities in the Media Control 
functional layer will allocate transport by communicating with the appropriate transport entities. 



CC info flow 


cc 










8.3 Definition of reference points 

Reference points are identified for those (groups of) information flows that are to be subject of standardization. The rest 
of this clause describes the reference points, defines in the IP Telephony Application plane and shows how they can be 
combined to provide the Telephony Application over IP Networks. 

This clause is structured as follows. Clauses 8.3.1 to 8.3.5 provide the registration and call scenarios. The subsequent 
clauses describe the reference points in more detail. 



8.3.1 Registration 
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Figure 12: Functions involved during the registration of a user 
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8.3.2 Scenario 1 




NOTE: For the simplicity only one Call Control function is showed within each network. However, one network 
may include more than one call control function with a reference point similar to the C2 reference point. 



Figure 13: Reference points for the Scenario 1 
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8.3.3 Scenario 2 
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NOTE: For the simplicity only one Call Control function is showed within each network. However, one network 
may include more than one call control function with a reference point similar to the C2 reference point. 



Figure 14: Reference points for the Scenario 2 



8.3.4 Scenario 3 
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NOTE: For the simplicity only one Call Control function is showed within each network. However, one network 
may include more than one call control function with a reference point similar to the C2 reference point. 



Figure 15: Reference points for the Scenario 3 
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8.3.5 Scenario 4 




IP Transport plane 



NOTE: For the simplicity only one Call Control function is showed within each network. However, one network 
may include more than one call control function with a reference point similar to the C2 reference point. 

Figure 16: Reference points for the Scenario 4 



8.3.6 SC-Service reference points 

SI: Information flows at SI provide the capability to store, retrieve and delete the registration ticket. 

S2: Information flows at S2 provide the capability to get and set properties in the User Profile. For the 

purposes of: User authentication, User authorization, Call routing, User preferences, Allowed services 
and service options. 

S3: Information flows at S3 provide the capability to get call routing information and address translation. 

8.3.7 SC-SC reference points 

Rl: Information flows at Rl provide the capability required for a user to register with the Serving IPTN. They 
provide the capability to convey user ID, terminal ID, terminal capabilities etc. 

R2: Information flows at R2 provide the capability so that networks can exchange user registration and 
information related to user profile and subscription. 

8.3.8 CC-SC reference points 

SCI: Information flows at SCI provide the capability to get a ticket on an existing registration session. 

SC2: Information flows at SC2 provide the capability to answer queries to the user profile. 

SC3: Information flows at SC3 provide the capability to answer access and routing requests for calls in the 
context of Network Functional Groupings. Input information may include called address/name, caller, 
calling domain. Output information may include next-hop address, preferences and constraints for the call 
parameters. 
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8.3.9 CC/BC-CC/BC reference points 

Cl: Information flows at CI provide the capability to establish, modify and terminate both calls and bearers to 
and from the terminal. 

C2: Information flows at C2 provide the capability to establish, modify and terminate both calls and bearers 
between non-terminal functional groupings. 

C3: Information flows at C3 provide the capability to establish, modify and terminate calls and connections 
between non-terminal functional groupings using an SCN. 

8.3.10 MC-BC reference points 

Nl: Information flows at Nl provide the capability to request, modify and delete media paths for the creation 
of a bearer in the context of Terminal Functional Grouping. 

N2: Information flows at N2 provide the capability to request, modify and delete media paths for the creation 
of a bearer and provides the capability to control an insertion of information (e.g. tones and 
announcements) into media flows in the context of Network Functional Grouping. 

N3: Information flows at N3 provide the capability to request, modify and delete media paths for the creation 
of a bearer in the context of Gateway Functional Grouping. 

N4: Information flows at N4 provide the capability to request, modify and delete media paths for the creation 
of a bearer and provides the capability to control an insertion of information (e.g. tones and 
announcements) into media flows in the context of Intermediate Gateway Functional Grouping. 

8.3.1 1 MC-MC reference points 

Ml: Information flows at Ml provide the capability to carry media flows between the terminal and the IPN. 
M2: Information flows at M2 provide the capability to carry media flows over the IPN. 
M3: Information flows at M3 provide the capability to carry media flows over the SCN. 



8.3.12 TR-MC reference points 



Tl: Information flows at Tl provide the capability to permit, modify and inhibit transport capabilities for the 

terminal, including Quality of Service, for the creation of a media flow. 

T2: Information flows at T2 provide the capability to permit, modify and inhibit transport capabilities for the 

IPTN, including Quality of Service, for the creation of a media flow. 

T3: Information flows at T3 provide the capability to permit, modify and inhibit transport capabilities for the 

SCN, including Quality of Service, for the creation of a media flow. 



9 Basic functional entities information sub-flows 

This clause contains the Message Sequence Charts (MSC) and definitions for primitives and their parameters for each 
reference point. 

Annex A contains an overview of functional entities, information flows, the Specification and Description Language 
(SDL) and functional entity actions from which the MSC diagrams in this clause are derived. 



9.1 Introduction 

There are request, confirmation, reject, report, and indication primitives defined. The Request primitive shall be used to 
request a function. The Confirm primitive shall be used to confirm that the Request has been completed. The Reject 
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primitive shall be used to reject the requested function. The Report primitives may be used to report events while a 
function is acting on a Request. The Indication primitives are used to report unsolicited events. 

9.2 Descriptors 

Some of the parameters used in the primitives are grouped. This sub-clause describes these groups. 

9.2.1 ServiceClass 

The ServiceClass represents the TIPHON QoS service class as defined in TS 101 329-2 [7]. It may take the following 
values: best, high, medium, low. 

9.2.2 FlowDescriptor 

The FlowDescriptor describes a media flow and contains information about the codec, terminal delay and a transport 
descriptor. 

9.2.3 BearerDescriptor 

The BearerDescriptor combines a ServiceClass and a list of FlowDescriptors offering multiple ways to achieve that 
ServiceClass. 

9.2.4 TransportDescriptor 

The TransportDescriptor provides all relevant information for the transport of a flow. It contains the following 
information: 

• maximum gross bit rate; the maximum bit rate of the CODEC including packetization and framing overhead, 

• delay budget; the allowed (remaining) delay for the flow, 

• packet rate; This parameter gives a hint to the transport to arrange the appropriate number of buffers, 

• packet delay variation; depending on network option either the allowed or achieved variation in the delay 
(jitter), 

• packet loss; depending on network option either the allowed or achieved loss of packets in transport, 

• originator transport address, the sending IP address and port, and 

• destination transport address; the receiving IP address and port. 
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9.3 Reference point C1 

Information flows at CI provide the capability to establish, modify and terminate both calls and bearers to or from the 
terminal. Reference point CI is placed between a terminal and network functional groupings. 

9.3.1 Primitives for Reference point C1 

The primitives and their parameters at reference point CI are defined in the table below. 



Table 1 : Table of C1 primitives and their parameters 
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reason {Congestion in the network, Called address non-existing or 
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not complete, Requested service not supported, Bearer request 






missing, Ticket not valid, Caller unauthorized, other} 
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CLCallReport. 


call ID 


M 


AddressComplete 






CLCallReport. 


call ID 


M 
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CLCallRequest 


call ID 


M 




called address 
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Requested Service {audio, video, data, ...} 


M 




ServiceClass 
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calling number presentation restriction indications 


M 




Caller location ID 







Priority 







bearerlD 


M 
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(Note 2) 
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call ID 


M 


NOTE 1 : The number of digits required parameter is required when the information is available in the SC layer. 


NOTE 2: The ticket parameter is mandatory in the terminal to network direction. 





ETSI 



27 



ETSI TS 101 314 V1.1.1 (2000-09) 



9.3.2 Information flows at Reference point C1 

The message sequence chart in the figure 17 describes the call setup between an originating terminal and another 
functional grouping. The primitive Cl.BearerConfirm can be sent either along the Cl.CallReport. Alerting or 
CLCallConfirm. 
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C1 .CallConfirm 





ACTIVE_PHASE 
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NOTE: The C1 .CallReportAddresslncomplete and the C1 .Additionallnfolndication may be repeated. 

Figure 17: Terminal-originated call flow at C1 
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The message sequence chart in the figure 18 describes the call setup between a Terminating Network Functional 
Grouping and a Terminating Terminal Functional Grouping. Please note that the primitive Cl.BearerConfirm can be 
sent either along the Cl.CallReport. Alerting or Cl.CallConfirm. 
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Figure 18: Terminal-terminated call flow at C1 
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9.4 Reference point C2 

Information flows at C2 provide the capability to establish, modify and terminate both calls and bearers between 
network functional groupings or gateway functional groupings. Reference point C2 is placed between two network 
functional groupings, between a network functional grouping and a gateway functional grouping, or between two 
gateway functional groupings. 

9.4.1 Primitives for Reference point C2 

The primitives and their parameters at reference point C2 are defined in the table below. 



Table 2: Table of C2 primitives and their parameters 



Primitive name 


Parameters 


Status 
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M 
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NOTE 1 : The Additional information indication parameter is mandatory when the Sending complete indication is 


absent. 






NOTE 2: The number of digits required parameter is required when the information is available in the SC layer. 
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Information flows at Reference point C2 
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NOTE: The C2.CallReportAddresslncomplete and the C2.Additionallnfolndication may be repeated. 

Figure 19: Network-network call setup information flow 
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9.5 Reference point C3 

Information flows at C3 provide the capability to establish, modify and terminate both calls and bearers over SCN. 
Reference point C3 is placed between a Gateway Functional Grouping and a SCN. 

9.5.1 Primitives for Reference point C3 

The primitives and their parameters at reference point C3 are defined in the table below. 



Table 3: Table of C3 primitives and their parameters 



Primitive name 


Parameters 


Status j 


C3.Additionallnformation 
Indication 


CalllD 

Additional called party address information 
Sending complete indication 


M 

O (Note 1) 
U (Note 1 ) 


C3.CallAndBearerRequest 


Called address 

Requested service {audio, video, data, ..} 
set of ( 
caller ID, 

calling number presentation restriction indications 
type of address 


M 

M 

M 
O 
O 




) 

call ID 
Circuit ID 
Priority 


M 

O (Note 2) 
O (Note 3) 


C3.CallAndBearerConfirm 


Call ID 
Circuit ID 


M 

O (Note 2) 


C3.CallReject 


Call ID 

reason {Congestion in the network, Called address non-existing or 
not complete, Requested service not supported, other} 


M 
M 


C3.CallReport. 
Addresslncomplete 


Call ID 

number of digits required 


M 

O (Note 4) 


C3.CallReport. 
AddressComplete 


Call ID 


M 


C3.CallReport. 
Alerting 


Call ID 


M 


C3.Releaselndication 


call ID 


M 


NOTE 1 : The Additional information indication parameter is mandatory when the Sending complete indication is 

absent from the message. 
NOTE 2: The circuit may be assigned either by source or destination. 

NOTE 3: Indicates that the call establishment shall be given a special priority, e.g. an emergency call. 

NOTE 4: The number of digits required parameter is required when the information is available in the SC layer. 
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9.5.2 Information flows at Reference point C3 



OGFG 

SCN | CC_BC 





C3.CallAndBearerRequest 







opt) 


C3.CallReport.Addresslncomplete 


1 


C3.Additionallnfolndication ^ 








optJ 


C3.CallReport.AddressComplete 













opt) 


C3.CallReport.Alerting 









C3.CallAndBearerConfirm 




~* 


ACTIVE_PHASE 








altJ 


C3.Releaselndication 


1 
1 






C3.Releaselndication 


1 












Figure 20: SCN-IPTN call setup information flow 

TGFG 



CC BC I SCN 




C3.CallAndBearerRequest 








optJ 


C3.CallReport.Addresslncomplete 


1 




C3.Additionallnfolndication 










optJ 


C3.CallReport.AddressComplete 













optJ 


C3.CallReport.Alerting 










C3.CallAndBearerConfirm 








ACTIVE_PHASE 









altJ 


C3.Releaselndication 


1 
1 

1 




C3.Releaselndication 











Figure 21 : IPTN-SCN call setup information flow 

NOTE: The C3.CallReportAddressIncomplete and the C3.AdditionalInfoIndication may be repeated. 
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9.6 Reference point N1 

Information flows at Nl provide the capability to establish, modify and terminate media flows between bearer control 
and media control within terminal functional grouping. Reference point Nl is placed between two network functional 
groupings, between a network functional grouping and a gateway functional grouping, or between two gateway 
functional groupings. 

9.6.1 Primitives for Reference point N1 

The information flow primitives and their parameters at reference point Nl are defined in the table below. 



Table 4: Table of N1 primitives and their parameters 



Primitive name 


Parameters 


Status 


N1 .MediaEstConfirm 


Bearer ID 


M 




Terminating siue 

Flow/Descriptors for received media 
FlowDescriptors for send media 
Media ID 



O 
M 




originating side 

FlowDescriptors for received media 
FlnwDp^rrintnr^ fnr ^pnd mpdia 

1 IUvi UvOvl 1 YJ Iw 1 O 1 \J 1 Ovl IU III w \-\ 1 CI 

Media ID 


O 

o 

M 


N1 .MediaEstRequest 


terminating side 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 


M 
M 
M 




nrininatinn cirlo 
ui ly ii icuii iy oiut; 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 


M 
M 
M 


NLMediaEstReject 


Bearer ID 
Reason 

nrininatinn cirlo 
ui iy ii icuii iy oiut; 

Media ID 


M 
M 

M 




terminating side 
Media ID 


M 


N1 .MediaActlndication 


originating side 
Media ID 

FlowDescriptors for received media 
FlowDescriptors for send media 


M 
O 





terminating side 
MedialD 

FlowDescriptors for received media 
FlowDescriptors for send media 


M 




N1 .MediaReleaseRequest 


originating side 
Media ID 


M 




terminating side 
Media ID 


M 


N1 .MediaReleaseConfirm 


Bearer ID 
originating side 
Media ID 


M 
M 




terminating side 
Media ID 


M 


N1 .MediaRsvConfirm 


Bearer ID 

originating side 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 


M 

M 
M 
M 
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terminating side 






Flow/Descriptors for received media 


M 




Flow/Descriptors for send media 


M 




Media ID 


M 


N1 .MediaRsvRequest 


Bearer ID 


M 




originating side 






Flow/Descriptors for received media 


M 




FlowDescriptors for send media 


M 




Media ID 


M 




terminating side 






FlowDescriptors for received media 


M 




FlowDescriptors for send media 


M 




Media ID 


M 


N1 .MediaRsvReject 


Bearer ID 


M 




Reason {Not enough resource available} 


M 




originating side 






Media ID 


M 




terminating side 






Media ID 


M 



9.6.2 Information flows at Reference point N1 



TFG TFG 



MC | BC 




N1 .MediaRsvRequest 






altJ 


N1 .MediaRsvConfirm 


1 
1 






N1 .MediaRsvReject 


1 






N1 .MediaEstRequest 







altJ 


N1 .MediaEstConfirm 


1 
1 






NLMediaEstReject 


1 










optJ 


N1 .MediaActlndication 


1 
1 











ACTIVE_PHASE 



NLMediaReleaseRequest 



N1 .MediaReleaseConfirm 



Figure 22: Call setup and call release information flows at N1 
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9.7 Reference point N2 

9.7.1 Primitives for Reference point N2 

The information flow primitives and their parameters at reference point N2 are defined in the table below. 



Table 5: Table of N2 primitives and their parameters 



Primitive name 


Parameters 


Status 


N2.MediaEstConfirm 


Bearer ID 


M 




terminating side 

FlowDescriptors for received media 
Flow/Descriptors for send media 
Media ID 


O 
O 
M 




originating side 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 


O 
O 
M 


N2.MediaEstRequest 


terminating side 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 


M 
M 
M 




originating side 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 


M 
M 
M 


N2.MediaEstReject 


Bearer ID 
Reason 

originating side 
Media ID 


M 
M 

M 




terminating side 
Media ID 


M 


N2.MediaActlndication 


originating side 
Media ID 

FlowDescriptors for received media 
FlowDescriptors for send media 


M 
O 
O 




terminating side 
Media ID 

FlowDescriptors for received media 
FlowDescriptors for send media 


M 
O 
O 


N2.MediaReleaseRequest 


originating side 
Media ID 


M 




terminating side 
ivieuia iu 


M 
IVI 


N2.MediaReleaseConfirm 


Bearer ID 
originating side 
Media ID 


M 
M 




terminating side 
Media ID 


M 


N2.MediaRsvConfirm 


Bearer ID 


M 




terminating side 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 


M 
M 
M 




originating side 

FlowDescriptors for received media 
FlowDescriptors for send media 


M 
M 
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Primitive name 




Status 




Media ID 


M 


N2.MediaRsvRequest 


Bearer ID 


M 




terminating side 






Flow/Descriptors for received media 


M 




Flow/Descriptors for send media 


M 




Media ID 


M 




originating side 






Flow/Descriptors for received media 


M 




FlowDescriptors for send media 


M 




Media ID 


M 


N2.MediaRsvReject 


Reason {Not enough resource available} 


M 




Bearer ID 


M 




originating side 






Media ID 


M 




terminating side 






Media ID 


M 



9.7.2 Information flows at Reference point N2 

NFG NFG 



MC BC 




N2.MediaRsvRequest 






altJ 


N2.MediaRsvConfirm 


1 
1 






N2.MediaRsvReject 


1 






N2.MediaEstRequest 







altJ 


N2.MediaEstConfirm 


1 
1 


► 




N2.MediaEstReject 


1 











optJ 


N2.MediaActlndication 


1 
1 











^ ACTIVE_PHASE ^> 




N2.MediaReleaseRequest 




N2.MediaReleaseConfirm 






Figure 23: Call setup and call release information flows at N2 
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9.8 Reference point N3 

9.8.1 Primitives for Reference point N3 

The information flow primitives and their parameters at reference point N3 are defined in the table below. 



Table 6: Table of N3 primitives and their parameters 



Primitive name 


Parameters 


Status 




N3.MediaEstConfirm 


Bearer ID 


M 




terminating side 

FlowDescriptors for received media 
Flow/Descriptors for send media 
Media ID 




M 




originating side 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 




M 


N3.MediaEstRequest 


terminating side 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 


M 
M 
M 




originating side 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 


M 
M 
M 


N3.MediaEstReject 


Bearer ID 
Reason 

originating side 
Media ID 


M 
M 

M 




terminating side 
Media ID 


M 


N3.MediaRsvConfirm 


Bearer ID 

Circuit ID 

originating side 

FlowDescriptors for received media 
FlowDescriptors for send mediacircuitID 
Media ID 


M 

M 
M 
M 




terminating side 

FlowDescriptors for received media 
FlowDescriptors for send mediacircuitID 
Media ID 


M 
M 
M 


N3.MediaRsvRequest 


Bearer ID 

Circuit ID 

originating side 

FlowDescriptors for received media 
FlowDescriptors for send mediacircuitID 
Media ID 


M 


M 

M 
M 




terminating side 

FlowDescriptors for received media 
FlowDescriptors for send mediacircuitID 
Media ID 


M 
M 
M 


N3.MediaActlndication 


originating side 

FlowDescriptors for received media 
FlowDescriptors for send mediacircuitID 
Media ID 


M 


M 




terminating side 

FlowDescriptors for received media 
FlowDescriptors for send mediacircuitID 
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Primitive name 




Status 




Media ID 


M 


N3.MediaReleaseRequest 


originating side 






Media ID 


M 




terminating side 






Media ID 


M 


N3.MediaReleaseConfirm 


Bearer ID 


M 




originating side 






Media ID 


M 




terminating side 






Media ID 


M 


N3.MediaRsvReject 


Bearer ID 


M 




originating side 






Media ID 


M 




terminating side 






Media ID 


M 



9.8.2 Information flows at Reference point N3 

GFG GFG 



MC BC 




N3.MediaRsvRequest 




~m 


altJ 


N3.MediaRsvConfirm 


1 
1 






N3.MediaRsvReject 


1 






N3.MediaEstRequest 






altJ 


N3.MediaEstConfirm 




1 
1 






N3.MediaEstReject 


1 










optJ 


N3.MediaActlndication 


1 
1 










ACTIVE_PHASE 




N3.MediaReleaseRequest 






N3.MediaReleaseConfirm 


>- 



Figure 24: Call setup and call release information flows at N3 

9.9 Reference point N4 

9.9.1 Primitives for Reference point N4 

The information flow primitives and their parameters at reference point N4 are defined in the table below. 
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Table 7: Table of N4 primitives and their parameters 



Primitive name 




Status 


N4.MediaEstConfirm 


Bearer ID 


M 




terminating side 

Flow/Descriptors for received media 
Flow/Descriptors for send media 
Media ID 


O 
O 
M 




originating side 

Flow/Descriptors for received media 
Flow/Descriptors for send media 
Media ID 


O 
O 
M 


N4.MediaEstRequest 


terminating side 

FlowDescriptors for received media 
Flow/Descriptors for send media 
Media ID 


M 
M 
M 




originating side 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 


M 
M 
M 


N4.MediaEstReject 


Bearer ID 
Reason 

originating side 
Media ID 


M 
M 

M 




terminating side 
Media ID 


M 


N4.MediaActlndication 


originating side 
Media ID 

FlowDescriptors for received media 
FlowDescriptors for send media 


M 

O 




terminating side 
Media ID 

FlowDescriptors for received media 
FlowDescriptors for send media 


M 
O 



N4.MediaReleaseRequest 


originating side 
Media ID 


M 




terminating side 
Media ID 


M 


N4.MediaReleaseConfirm 


Bearer ID 
originating side 
Media ID 


M 
M 




terminating side 
Media ID 


M 


N4.MediaRsvConfirm 


Bearer ID 


M 




terminating side 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 


M 
M 
M 




originating side 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 


M 
M 
M 


N4.MediaRsvRequest 


Bearer ID 


M 




terminating side 

FlowDescriptors for received media 
FlowDescriptors for send media 
Media ID 


M 
M 
M 
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Primitive name 








originating side 






FlowDescriptors for received media 


M 




Flow/Descriptors for send media 


M 




Media ID 


M 


N4.MediaRsvReject 


Reason {Not enough resource available} 


M 




Bearer ID 


M 




originating side 






Media ID 


M 




terminating side 






Media ID 


M 



9.9.2 Information flows at Reference point N4 

GFG GFG 

MC I I BC 





N4.MediaRsvRequest 







altJ 


N4.MediaRsvConfirm 


1 
1 






N4.MediaRsvReject 


1 






N4.MediaEstRequest 







altJ 


N4.MediaEstConfirm 


1 
1 






N4.MediaEstReject 


1 










optJ 


N4.MediaActlndication 


1 
1 











ACTIVE_PHASE 





N4.MediaReleaseRequest 




N4.MediaReleaseConfirm 







Figure 25: Call setup and call release information flows at N4 

9.10 Reference point M1 

The information flow at this reference point comprises one-way or two-way media flows and their associated statistics. 

9.1 1 Reference point M2 

The information flow at this reference point comprises one-way or two-way media flows and their associated statistics. 

9.12 Reference point M3 

The information flow at this reference point comprises one-way or two-way media flows and their associated statistics. 
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9.13 Reference point T1 

9.13.1 Primitives for Reference point T1 

The information flow primitives and their parameters at reference point Tl are defined in the table below. 



Table 8: Table of T1 primitives and their parameters 



Primitive namp 


Parameters 


Status 


n.i ransporitsTL/OnTirrn 


Receiving i ransportuescripior 


KA 
IVI 




trancnnrtin 
Lldl IbpUl LIU 


M 

IVI 




^onrlinn Trancnnrtriocr^rin+nr 
oci iuii ly i i cti lofjui lucbui ijjlui 


M 

IVI 




iranspcTT iu 


IVI 


1 1 . 1 idllbpuilCblricJcOL 


LldilbpurilU 


KA 

IVI 




nedbur l 


IVI 


n.i ranspori£STriec|uesi 


Receiving i ranspon.uescripi.or 


h /I 
IVI 




LidllbpOilIU 


IVI 




Sending TransportDescriptor 


IVI 




trancnnrtin 
Lldl IbpUl LIU 


IVI 


n.i ransporAciinaicaiion 


Receiving transportID 


h /I 
IVI 




Sending transportID 


KA 

IVI 


n.i ransporirieieaseriec|U6Si 


receiving transportiu 


h /I 
IVI 




senuing transportiu 


KA 
IVI 


i i . i ranspunneieabeoonTirrTi 


receiving 






transportID, 


M 




statistics 







sending 






transportID 


M 




statistics 





T1 .TransportRsvConfirm 


MedialD 


M 




Sending TransportDescriptors 


M 




transportID 


M 




Receiving TransportDescriptors 


M 




transportID 


M 


T1 .TransportRsvReject 


MedialD 


M 




TransportDescriptor 


M 




Reason {Not enough resources available, other} 


M 


T1 .TransportRsvRequest 


MedialD 


M 




Sending TransportDescriptor 


M 




Receiving TransportDescriptor 


M 
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9.1 3.2 Information flows at Reference point T1 



TFG TFG 



IP M 




T1 .TransportRsvRequest 







altJ 


T1 TransportRsvConfirm 


1 
-| 







T1 TransportRsvReject 


1 






T1 TransportEstRequest 







altJ 


T1 .TransportEstConfirm 


1 
1 






T1 .TransportEstReject 


1 










optJ 


T1 .TransportActlndication 


1 
1 












ACTIVE_PHASE 



T1 TransportReleaseRequest 



T1 .TransportReleaseConfirm 



Figure 26: Call setup and call termination at T1 

9.14 Reference point T2 

9.1 4.1 Primitives for Reference point T2 

The information flow primitives and their parameters at reference point T2 are defined in the table below. 



Table 9: Table of T2 primitives and their parameters 



Primitive name 






T2.TransportEstConfirm 


originating side 






ReceivingTransportDescriptor 


M 




transportID 


M 




Sending TransportDescriptor 


M 




transport ID 


M 




terminating side 






ReceivingTransportDescriptor 


M 




transportID 


M 




Sending TransportDescriptor 


M 




transport ID 


M 


T2.TransportEstReject 


transport ID 


M 


T2.TransportEstRequest 


originating side 






ReceivingTransportDescriptor 


M 




transportID 


M 




Sending TransportDescriptor 


M 




transport ID 


M 




terminating side 






ReceivingTransportDescriptor 


M 
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Status 




transportID 


M 




Sending TransportDescriptor 


M 




transport ID 


M 


T2.TransportActindication 


Originating side 






Receiving transport ID 


M 




Sending transport ID 


M 




Terminating side 






Receiving transport ID 


M 




Sending transport ID 


M 


T2.TransportReleaseRequest 


originating side 






receiving transportID 


M 




sending transportID 


M 




terminating side 






receiving transportID 


M 




sending transportID 


M 


T2.TransportReleaseConfirm 


oriainatina side 






receiving 






transportID, 


M 




statistics 


O 




sending 






transportID 


M 




statistics 


O 




terminating side 






receiving 






transportID, 


M 




statistics 


O 




sending 






transportID 


M 




statistics 


O 


T2.TransportRsvConfirm 


Originating side 






MedialD 


M 




Sending TransportDescriptors 


M 




transportID 


M 




Receiving TransportDescriptors 


M 




transportID 


M 




Terminating side 






MedialD 


M 




Sending TransportDescriptors 


M 




transportID 


M 




Receiving TransportDescriptors 


M 




transportID 


M 


T2.TransportRsvReject 








originating side 






Media ID 


M 




ReceivingTransportDescriptor 


M 




transportID 


M 




Sending TransportDescriptor 


M 




transport ID 


M 




terminating side 






Media ID 


M 




ReceivingTransportDescriptor 


M 




transportID 


M 




Sending TransportDescriptor 


M 




transport ID 


M 


T2.TransportRsvRequest 








originating side 






Media ID 


M 




ReceivingTransportDescriptor 


M 




transportID 


M 




Sending TransportDescriptor 


M 




transport ID 


M 
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terminating side 






Media ID 


M 




ReceivingTransportDescriptor 


M 




transportID 


M 




Sending TransportDescriptor 


M 




transport ID 


M 



9.1 4.2 Information flows at Reference point T2 



NFG NFG 



IP | M 




T2.TransporlRsvRequest 







altJ 


T2.TransportRsvConfirm 


1 
1 






T2.TransportRsvReject 


1 






T2.TransportEstRequest 






altJ 


T2.TransportEstConfirm 


1 
1 






T2.TransportEstReject 


1 










optJ 


T2.TransportActlndicalion 


1 
1 











ACTIVE_PHASE 




T2.TransportReleaseRequest 






T2.TransportReleaseConfirm 


»~ 



Figure 27: Call setup and call termination at T2 
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9.15 Reference point T3 

9.1 5.1 Primitives for Reference point T3 

The information flow primitives and their parameters at reference point T3 are defined in the table below. 



Table 10: Table of T3 primitives and their parameters 



Drimitix/a name 
~ 1 1 1 1 1 1 U vc? lldlllc? 


Paramotorc 


OLdLUb 


TrancnnrtPctPnnf irm 
1 O . 1 1 ctl IbpUl LiZblOUI 1 1 II 1 1 1 


ncuciviiiy 1 1 di lbpui iLJcboi ipiui 


M 
IVI 




tranennrtin 

LI ctl lopUl LI U 


M 

IVI 




OfcJIIUIMy 1 rdllbpuriUtJbOlipLUI 


M 
IVI 




tranennrt in 

LI ctl IbpUl L 1 u 


M 

IVI 


TrancrmrtFctRoio/^t 
1 O. 1 leu lo|JUi LColrifcfJcOL 


tranennrtin 
LI ctl IbpUl LIU 


M 

IVI 


i o. i ransporttstriequest 


neceiving i ransportuescriptor 


KA 
IVI 




TransporTiu 


KA 
IVI 




SGnding TransportDescriptor 


KA 
IVI 




tranennrtin 
LI ctl IbpUl LIU 


IVI 


a — i — ;n — ■ 

T3.TransporActt Indication 


RGCGiving transportlD 


KA 
IVI 




OtJllUlliy lldllbpUlllLJ 


M 
IVI 


TrT~i B 

T3.TransportReleaseReo,u 


receiving transportlD 


KA 
IVI 


GSt 


conrlinn trancnnrtin 
btiMUIMy UculopUIUL' 


IVI 


T3.TransportReleaseConfi 


receiving 




rm 


transportlD, 


M 




statistics 







sending 






transportlD 


M 




statistics 





T3.TransportRsvConfirm 


MedialD 


M 




Sending TransportDescriptors 


M 




Transport ID 


M 




Receiving TransportDescriptors 


M 




Transport ID 


M 


T3.TransportRsvReject 


MedialD 


M 




TransportDescriptor 





T3.TransportRsvRequest 


MedialD 


M 




Sending TransportDescriptor 


M 




Receiving TransportDescriptor 


M 
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9.1 5.2 Information flows at Reference point T3 



GFG GFG 



IP | M 




T3.TransportRsvRequest 






altJ 


T3.TransportRsvConfirm 


1 
1 







T3.TransportRsvReject 


1 


^> 




T3.TransportEstRequest 






altJ 


T3.TransportEstConfirm 


1 
1 







T3.TransportEstReject 


1 










optJ 


T3.TransportActlndication 


1 
1 












ACTIVE_PHASE 



T3.TransportReleaseRequest 



T3.TransportReleaseConfirm 



Figure 28: Call setup and call termination at T3 
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9.16 Reference point SC1 

9.1 6.1 Primitives for Reference point SC1 

Table 11 : Table of SC1 primitives and their parameters 



Primitive name 


Parameters 


Status 


SC1 .0_ServiceRequest 


Requested Service{audio, video, fax, data, other} 


M 


SC1 .0_ServiceConfirm 


UserlD 


M 




Ticket 


M 




ServiceProvider Address 


M 




Service Details {QoS class, etc} 


M 


SC1.0_ServiceReject 


Reason { No valid ticket for the service(s), other} 


M 


SC1.T-ServiceReject 


Reason {No valid ticket for the service(s), other} 


M 


SC1 T-ServiceRequest 


Requested Service{audio, video, fax, data, other} 


M 




Calling party address (Address, Screening, etc) 


M (Note) 




Called party address (Address, Screening, etc) 


M 


SC1 T-ServiceConfirm 


UserlD 


M 




Ticket 


M 




ServiceProvider Address 


M 




Service Details {QoS class, etc} 


M 


SC1.T-ServiceReject 


Reason {No valid ticket for this service, other} 


M 


NOTE: The parameter is mandatory, however, it may contain null information, e.g., when presentation is not 


allowed. 







9.1 6.2 Information flows at Reference point SC1 



TFG 



TFG 



cc 




cc 











Originating_ Call 




SC1 .0_ServiceRequest 






altJ 


SC1 .0_ServiceConfirm 


1 
1 







SC1 .0_ServiceReject 


1 

















Terminating_ Call 




SC1 .TServiceRequest 






altJ 


SC1 TServiceConfirm 


1 
1 






SC1 T_ServiceReject 




1 











Figure 29: Information flows at Reference point SC1 



ETSI 



48 



ETSI TS 101 314 V1.1.1 (2000-09) 



9.17 Reference point SC2 

9.1 7.1 Primitives for Reference point SC2 

The information flow primitives and their parameters at reference point SC2 are defined in the table below. 



Table 12:Table of SC2 primitives and their parameters 



Primitive namo 

i 1 1 1 1 1 1 LI VC 1 Idl 1 IC 




OV_/£i .MOOubbMi 1U nUU 11 1 ly \j 


service class, 


M 


r\ t~\i i rim 
Ul Hill II 


Resource capability limit 


u 




Allowed service {audio, video, data, other} 


M 




calling number presentation restriction indications 


M 




route info, 


M 




destinations 


M 




call ID 


M 


SC2. AccessAndRouti ng R 


call ID 


M 


eject 


reason {Number incomplete, other} 


M 




Number of digits needed 


O (Note) 1 


SC2.AccessAndRoutingR 


called address 


M 


equest 


caller ID (normally includes an E.164 [1] /Private Numbering Plan [2] and 


M 




[3] style number) 






calling number presentation restriction indications 


M 




call ID 


M 




service Class 


M 




Requested service {audio, video, data, other} 


M 




Resource capability limit 


O 




Priority 


O (Note 2) 




Ticket 


O 


NOTE 1 : Only sent when the information is available. 




NOTE 2: Indicates that the call establishment shall be given a special priority, e.g. an emergency call. 



9.1 7.2 Information flows at Reference point SC2 



cc sc 




SC2..AccessAndRoutingRequest 




^ 


altJ 


SC2..AccessAndRoutingConfirm 


1 
1 







SC2..AccessAndRoutingReject 


1 












Figure 30: Information flows at Reference point SC2 
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9.18 Reference point SC3 

9.1 8.1 Primitives for Reference point SC3 

The information flow primitives and their parameters at reference point SC3 are defined in the table below. 



Table 13: Table of SC3 primitives and their parameters 



Primitive name 


Parameters 


Status 


SC3.AccessAndRouting 


call ID 


M 


Confirm 


Allowed service {audio, video, data, other} 


M 




calling number presentation restriction indications 


O 




route info, 


M 




destinations 


M 




called address 


0(Note 1) 


SC3.AccessAndRouting 


call ID 


M 


Reject 


reason {Number incomplete, other} 


M 


SC3.AccessAndRouting 


called address 


M 


Request 


Requested service {audio, video, data, other} 


M 




caller ID (normally includes an E.164 [1] /Private Numbering Plan [2] 


M 




and [3] style number) 






calling number presentation restriction indications 


M 




call ID 


M 




service Class 


O 




Resource capability limit 


O 




Priority 


O (Note 2) 


NOTE 1 : Only sent when the called Address is modified. 




NOTE 2: Indicates that the call establishment shall be given a special priority, e.g. an emergency call. 



cc sc 




SC3.AccessAndRouting Request 







altJ 


SC3 .AccessAndRoutingConfirm 


1 
1 






SC3.AccessAndRouting Reject 


1 












Figure 31 : Information flows at Reference point SC3 
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9.1 9 Reference point S1 

Information flows S 1 provide the capabilities to authorize and authenticate incoming or outgoing service or call 
requests by terminal functional groupings. 

9.1 9.1 Primitives for Reference point S1 



Table 13A: Table of S1 primitives and their parameters 



rrimiuvc name 


nara meters 


Dial US 


Q1 I Icor Inf n Rom loct 
o I .Uacl II HUncqUcol 


I ict r»f Rom ioc+oH cor\/iroc/ai iHir\ \/irlon fav Hatci ntho r\ 
LlbL Ul ntJ^UooLoU ocl V IOco|dUUIU, VlUcU, IdX, UcLLct, ULIIfcJI/ 


1 VI 


o i .useririTuounTir in 


List ot (Aiiowea services(auuio, viaeo, tax, uata, otnerj 


IVI 




usenu 


IVI 




ServiceProviderlD) 


M 
IVI 


— — ; ; — ; 

S1 .Registrationlndication 


List of (Allowed servicesjaudio, video, data, other} 


IVI 




Ticket 


(J 




ServiceProviderAddress 


M 

IVI 




1 Icorin 


IVI 




Registration ID) 


M 


S1 .Deregistrationlndication 


List of (Allowed services {audio, video, data, other} 


M 




Registration ID) 


M 


S1 .0-ServiceRequest 


Requested Service{audio, video, fax, data, other} 


M 


S1 .0-ServiceConfirm 


UserlD 


M 




Ticket 







ServiceProvider Address 


M 




Service Details {QoS class, etc} 


M 


S10-ServiceReject 


Reason {No valid ticket for this service, other} 


M j 


S1 T-ServiceRequest 


Requested Service{audio, video, fax, data, other} 


M 




Calling party address (Address, Screening, etc) 


M (Note) 




Called party address (Address, Screening, etc) 


M 


S1 T-ServiceConfirm 


UserlD 


M 




Ticket 







ServiceProvider Address 


M 




Service Details {QoS class, etc} 


M 


S1T-ServiceReject 


Reason {No valid ticket for this service, other} 


M 


NOTE: The parameter is mandatory however it may contain null information e.g. when presentation is not 


allowed. 
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9.1 9.2 Information flows at Reference point S1 



OTFG 
SC 



OTFG 



Service_ 
Profile 





S1 .UserlnfoRequest 




S1 .UserlnfoConfirm 


-« 




S1 .Registrationlndication 







Registered 










S1 .Deregistrationlndication 






^ Deregistered ^ 





Figure 32: Registration information flows at Reference point S1 

OTFG 



OTFG 
SC 



Service_ 
Profile 





S1.0 ServiceRequest 







altJ 


S1 .0_ServiceConfirm 


1 
1 







S1 .0 ServiceReject 


1 


M 










S1 .TServiceRequest 






altJ 


S1 TServiceConfirm 


1 
1 







S1 .TServiceReject 


1 


M 



Figure 33: Call-related information flows at Reference point S1 
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9.20 Reference point S2 

Information flows S2 provide the capabilities apply user-specific services, routing or access limits on the network 
functional grouping. 

9.20.1 Primitives for Reference point S2 

The information flow primitives and their parameters at reference point S2 are defined in the table below. 



Table 14: Table of S2 primitives and their parameters 



Primitive name 


Parameters 


Status 


S2.UserRoutingConfirm 


calllD 


M 




routing info 


O 




destinations 


O 




service 


O 




service class 


O 




resource capability limit 


O 




Priority 


M 




Presentation number & restrictions 


O 


S2.UserRoutingReject 


calllD 


M 




reason 


M 


S2.UserRoutingRequest 


calllD 


M 




caller ID (normally includes an E.164 [1] /Private Numbering Plan [2] 


O 




and [3] style number) 






calling number presentation restriction indications 


O (Note) 




called address 


M 




service 


O 




service class 


O 




resource capability limit 


O 




Priority 


M 




Ticket 


O 


NOTE: The calling number presentation restriction indications parameter is mandatory when the caller ID 


parameter is present. 





9.20.2 Information flows at Reference point S2 



cc I sc 




S2.UserRoutingRequest 
*~ 






altJ 


S2.UserRoutingConfirm 


1 
1 






S2.UserRouting Reject 


1 


~« 









Figure 34: Information flows at Reference point S2 
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9.21 Reference point S3 

Information flows S3 provides the capabilities for non-user-specific call access control and routing. 

9.21 .1 Primitives for Reference point S3 

The information flow primitives and their parameters at reference point S3 are defined in the table below. 



Table 15: Table of S3 primitives and their parameters 



Primitive name 




Status 


S3.ValidateRoutingConfirm 


call ID 

nouiing inrormaiion (aoaress wnere io rouie me can j 


M 

KA 
IVI 


S3.ValidateRoutingReject 


call ID 

reason (Aoaress mcompieie, oiner)) 


M 

KA 
IVI 


S3.ValidateRoutingRequest 


called address 

service (e.g. voice 3,1 kHz audio) 

caller ID (normally includes an E.164 [1] /Private Numbering Plan 
[2] and [3] style number) 

calling number presentation restriction indications 

call ID 

Priority 


M 
M 
M 
M 
M 
M 

O (Note 1) 


S3.AccessRoutingConfirm 


call ID 

Routing information (address where to route the call) 


M 
M 


S3.AccessRoutingRequest 


called address 

service (e.g. voice 3,1 kHz audio) 

caller ID (normally includes an E.164 [1] /Private Numbering Plan 
[2] and [3] style number) 

calling number presentation restriction indications 

call ID 

Priority 


M 
M 
O 

O (Note 2) 


S3.AccessRoutingReject 


call ID 

reason {Address incomplete, other}} 


M 
M 


NOTE 1 : The calling number presentation restriction indications is mandatory when the caller ID is present. 
NOTE 2: Indicates that the call establishment shall be given a special priority, e.g. an emergency call. 



9.21 .2 Information flows at Reference point S3 



cc sc 




S3.ValidateRoutingRequest 






altJ 


S3.ValidateRoutingConfirm 


1 
1 







S3.ValidateRouting Reject 


1 







S3 .AccessRouting Request 







altJ 


S3.ValidateRoutingConfirm 


1 
1 






S3.ValidateRoutingReject 


1 












Figure 35: Information flows at Reference point S3 
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9.22 Reference point R1 

9.22.1 Primitives for Reference point R1 



Table 16: Table of R1 primitives and their parameters 



Primitivo 

1 1 1 1 1 1 1 LI vc 


Pa pa motor 

ral dl 1 It LCI 


Qtnti iq 


n I . ncy lo LI ctLIU I IUUI II 1 1 1 1 1 


1 leprin 
Ubcl 1 U 

List of Service address [Allowed Servicejaudio, video, fax, data, 

other}] 

Ticket 


Kyi 

IVI 

O (Note 1 ,2) 
M 


RLRegistrationReject 


UserlD 

reason{Unknown user, Already registered elsewhere, other} 


M 
M 


R1 .RegistrationRequest 


User ID 

Requested service(s) {audio, video, fax, data, other} 
Terminal ID 

Terminal details{ID, type of terminal, other details} 


M 

O (Note 1 ,2) 

O 

O 


R1 .DeregistrationConfirm 


UserlD 


M 


R1 .DeregistrationReject 


UserlD 

Reason {Not registered, other} 


M 
M 


R1 .DeregistrationReport 


UserlD 


M 


R1 .DeregistrationRequest 


UserlD 


M 


NOTE 1 : Optional when the User profile function and the SC function (where the Terminal network registers) 

reside in the same service provider network. 
NOTE 2: Details about supplementary services and their status is out of scope of the present document. 



9.22.2 Information flows at Reference point R1 

TFG Serving NFG 

I SC I I SC 



Serving_ NFG_ Discovered 
/* FFS in WG7 */ 



R1 .RegistrationRequest 



Authentication 
/* FFS in WG8 */ 



R1 .RegistrationConfirm 



R1 .DeregistrationRequest 



R1. DeregistrationConfirm 




Figure 36: Information flows at Reference point R1 
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9.23 Reference point R2 

9.23.1 Primitives for Reference point R2 



Table 17: Table of R2 primitives and their parameters 



Primitive 




Status 


R2.UserRegistrationConfirmation 


UserlD 

List of Service address [Allowed Servicejaudio, video, 
Tax, uaia, oinerjj 

Allowed Service(s) {audio, video, fax, data, other} 

OclvlUt; Ulabo 

number presentation restrictions 
Ticket 


M 

O (Note 1 ,2) 

O (Note 2) 

O 
O 


R9 I IcorRonictratinn Roioft 
n^.uoci ncyioLi cuiui incjooL 


Reason {Unknown user, Already registered elsewhere, 
other} 

tprminalin /IH t\/np nf tprminal nthpr HptailQl 

LCI 1 1 1 II Idl 1 LJ ill-', Ly[JC Ul Id 1 1 II 1 Idl , L>LI ICI UCLClllOf 


M 

IVI 

M 
O 
n 


R2.UserRegistrationRequest 


UserlD 
Tprminpl ID 

Terminal details{ID, type of terminal, other details} 
User location details 

Requested service(s) {audio, video, fax, data, other} 
Address of Home Service ID 
User location details 


M 

O (Notp 31 
O (Note 3) 
O 

O (Note 1) 
O (Note 4) 
O (Note 5) 


R2.UserDeregistrationConfirm 


UserlD 

User location details 


M 

O (Note 5) 


R2.UserDeregistrationReject 


UserlD 

Reason {Not registered, other} 
User location details 


M 
M 

O (Note 5) 


R2.UserDeregistrationReport 


UserlD 

User location details 
Statistics 


M 

O (Note 5) 
O 


R2.UserDeregistrationRequest 


UserlD 

User location details 


M 

O (Note 5) 


NOTE 1 : Requested Service(s)/Allowed Service(s) is mandatory when a subset of subscribed services is 

requested. The User profile function shall screen the Requested Service(s) parameter and only return 
the allowed service(s). 

NOTE 2: Details about supplementary services and their status is out of scope of the present document. 

NOTE 3: Mandatory when the user may register from more than one terminal at the same time. 

NOTE 4: Optional when the User profile function and the SC function (where the Terminal network registers) 

resides in the same service provider network. 
NOTE 5: The sending service provider network may provide (local) details only understandable by the sender. 

Those details shall always be provided in all communication between the network where the User 

profile resides and the sending Services provider network. 
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9.23.2 Information flows at Reference point R2 



sc 


serRegistration Request 


SC 




R2.U 









Authentication 
/* FFS in WG8 */ 



User Information and Profile Transfer 
/* FFS in WG7 */ 




R2.UserRegistrationConfirm 




-m 




R2 . UserDereg istration Request 







User_ lnformation_ and_ Profile_ Release 
/* FFS in WG7 */ 



R2.UserDeregistrationConfirm 



Figure 37: Information flows at Reference point R2 
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Annex A (normative): 

Overview of functional entities and information flows 

The Message Sequence Charts (MSCs) show information flows between functions required for registration and normal 
call within and between functional layers in the IP Telephony Application plane. The information flows also show 
communication with the IP Transport plane and the SCN plane. 

In the event of incompatibility between the SDL diagrams and the message sequence charts the SDL shall take 
precedence. 



A.1 Registration 



Figure A.l shows the information flow when a user registers to a Serving Network functional grouping. The location 
information is forwarded to the Home Network functional grouping using the SC2.UserRegistrationRequest primitive. 

Actions in the figure A.l are described below. 



MSC RegistrationthroughServinglPTN 



UI.LoginRequest 



Service_ 
Profile 



S1 .UserlnfoRequest 



SLUserlnfoConfirm 



Serving NFG 
I sc I 



Serving_ NFG_ Discovered 
/* FFS in WG7 7 



R 1 . Regi st rati o n Req ue st 



R2.UserRegistrationRequest 



Authentication 
i' FFS in WG8 V 



UI.LoginConfirr 



User_ lnformation_ and_ Profile_ Transfer 
r FFS in WG7 */ 



RLRegistrationConfirm 



R2.UserRegistrationConfirm 



Home_ 
Profile 



SLRegistrationlndication 



< 



User_ Registration_ Complete 



Figure A.1 : Information flows during the registration. 



Figure A.2: Information flows during the deregistration 
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A.1 .1 Service functional layer 



Deregistered 



Registered 



S1 .Registration 
Indication 



S1 .Deregistratiipn 
Indication 



Store the tickets... 



Registered 



Deregistered 



Figure A.3: Storing tickets in the Service Profile in a terminal FG 




\ S1 .Userlnfo_ 
/ Request 



To be defined 



S1.Userlnfo_ 
Confirm 



Figure A.4: User info request in a terminal FG 
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A.1 .2 Service Control functional layer 




Figure A.5: Terminal FG registration, part 1 



NOTE: Actions in the terminal functional grouping is beyond the scope of the present document. However, it can 
be assumed that the Registration function within the Service Control functional layer informs the user 
regarding the progress of the registration/deregistration process by means of applicable indications. For 
example, the SC layer can ask user profile for user information, as shown in figure A.5 above. 




Disoover_ 
Serving_ 
Network 



R1. Registration 
Request 



Sends a registration 
request towards serving 
network asking user to be 
registered with it 



Registering 



R1 .Registration/ 
Confirm 



S1 .Registration_ 
Indication 



User registration is 
complete with this 
terminal 



Store the tickets 
to the service profile 



R1 .Registration 
Reject 



Ul. Login 
Reject 



Inform the user about 
~] registration rejection 



UI.Login_ 
Confirm 



Inform user of successful 
registration 



Deregistered 



Registered 



Figure A.6: Terminal FG registration 
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Deregistered 



R1. Registration 
Request 



Registering 



R2.User_ 

Registration 

Confirm 



R2.UserRegistration 
Request 



The service control locates 
the User's home network 
functional grouping. 

The user's location information is 
forwarded to the home network. 
The means for locating User's 
home network is beyond scope 
of ths document 



R1. Registration 
Complete 



The service control function stores 
applicable user information required 
for basic call setup. 

The Registration confirmation is 
forwarded to the terminal. 



Registering 



Registered 



Figure A.7: Serving or Intermediate Network FG registration 

NOTE: The means for locating the home network functional grouping is out of scope of the present document. 




Authenticate 



The home NFG updates the location 
of the user. It may cancel the 
registration from the previous 
serving NFG, authenticate the 
user and transport user 
information to the 
serving NFG. 



UserProfile_ 
Transfer 





The home NFG cancels the 
registration of the user. 



Figure A.8: Home network FG registration and deregistration 
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Registered 



/ \ 
I Deregistering j 



R1.Deregistration_ 
Request 



R2.User_ 

Deregistration_ 

Request 



Deregistering 



The cancellation of the user's 
-i registration is forwarded 
to the home network. 



R2.User_ 

De registration^ 

Confirm 



The service control deletes the user 
! t information from its databases. 
The unregistration confirmation should 
be forwarded to the terminal 



R1.Deregistrat.ion 
Complete 



De registered 



Figure A.9: Serving Network FG deregistration 

NOTE: The reasons for deregistration of the User is beyond the scope of the present document. 




Deregistering 



j Note: unsuccessful 
■ \ deregistration is FFS 



RLDeregistratiC; 
Confirm 



S1 .Deregistration_ 
Indication 



UI.Logout_ 
Confirm 



Deregistered 



Figure A.10: Terminal FG deregistration 
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Registered, 
Degistering 



R1 .Deregistrati 
Indication 




Network -initiated 
deregistration 



S1 .Deregistration^v 
Indication / 



UI.Logout_ 
Indication 



Deregistered 



Figure A.11: Network initiated Terminal FG deregistration 
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A.2 Call control 

A.2.1 Originating Gateway FG 

The Originating gateway functional grouping implements the SCN Interworking Function (SCNIWF) e.g. a gateway. 
The figure A. 12 shows the information flow within the SCN Interworking function required for a basic call setup on the 
incoming side of the call. 



MSC Call_SetupJn_Originating_Gateway 

OGFG OGFG OGFG OGFG OGFG OGFG FG 



| SCN ] [ IP ] T MC 1 [ BC "j f CC i f SC ""> | Services ~| ; Next j 





C 3. Call And Bearer 
Reauest 








SC3.AccessAnd: 
RoutinaReouest 


S3.ValidateRouting_ 
Request 


















optJ 








C3.CallReport._ 
AddresslncomDlete 


SC3.AccessAnd_ 
RoutinaReiect 


S3.ValidateRouting_ 
Reiect 




1 
1 


C3.Additionallnfo 
Indication 








SC3.AccessAnd_ 
RoutingRequest 


S3.Va!idateRouting_ 
Request 


















T3.TransportRsv 
Request 


N3.MediaRsv 
Request 


BearerRsv 
Request 


SC3.AccessAnd 
RoutingConfirm 


S3.ValidateRouting_ 

S3.AccessRouting_ 
Request 

S3.AccessRouting 
Confirm 






T3.TransportRsv_ 
Confirm 


N3.MediaRsv_ 
Confirm - 


Bearer Rsv_ 
-Confirm 


C2.Call 
Request 








C2. Bearer 
Request 
















optJ 








C3.Call Report. 
Address Incomplete 






C2. Call Report. 
Addresslncomplete 


1 


C3. Additional Info 
Indication 








C2.Additionallnfo 
Indication 






1 
















optJ 














C2.Call Report. 
AddressComplete 


2 
2 








optJ 








C3. Call Report. 
AddressComplete 








2 
2 














T3.TransportEst 
Request 


N3.MediaEst 
Request 








C2.Bearer__ 
Confirm 




T3.TransportEst 
Confirm 


N3.MediaEst 
Confirm 


Bearer Est 
Indication 














optJ 








C3.CallReport._ 
Alertina 






C2.CallReport._ 
Alertina 


1 
1 






























C2.Call 
Confirm 










optJ 




T3.TransportAct 
m Indication 


N3.MediaAct 
m Indication 


BearerAct 
m Indication 








1 
1 
















C3.Call_ 
Confirm 


r 














1 



<^ ACTIVE_PHASE > 

I I I I I I I I 

NOTE 1 : The sender of the Bearer request shall be prepared to receive media as soon as the Bearer request is 
transmitted. 

NOTE 2: The Cn.CallReportAddresslncomplete and the Cn.Additionallnfolndication may be repeated. 

Figure A.12: Information flows at the Originating Gateway Functional Grouping at call establishment 

phase 

The Originating gateway functional grouping receives a clearing indication from the SCN when the calling party clears. 
The release indication is transferred to the next functional grouping and the bearer is released within the SCN. 
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The Originating gateway functional grouping receives a clearing indication from the next functional grouping when the 
Called party clears. The release indication is transferred to the next functional grouping and the bearer is released within 
the SCN. 

The figure A. 13 shows the detailed information flow required for clearing the call. 



MSC CalLReleaseJnOriginatingGateway 

OGFG OGFG 



SCN 



MC 



> 



ACTIVE_PHASE 





















altJ 


C3. Release 
Indication 








C2. Release 
Indication 






1 
1 
























C3. Release 
Indication 






C2. Release 
Indication 


1 




















T3.TransportRelease 
Reques 


N3.MediaRelease_ 
Request 


Bearer Release_ 
Request 










T3.TransportRelease_ 
Confirm 


N3.MediaRelease_ 
Confirm 


Bearer Release_ 
Confirm 









Figure A.13: Information flows at the Originating Gateway Functional Grouping at call teardown 

phase 

A.2.1 .1 The Services functional layer 

The behaviour of the Services functional layer is implementation dependent. The Services functional layer is expected 
to respond to requests made from the Service Control functional layer with appropriate parameters. 
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.1 .2 The Service Control functional layer 



Null 



SC3 AccessAnd ' Rec 1 uests tne Services functional layer 
X ioutinaReauest" n t0 validate and Perform routing analysis 

.uuuiyneques anrl tranclatinn ao rani liraH tn onahla 



(addr) 



S3.ValidateRouting 
Request(addr) , 



and translation, as required to enable 
Jhe call to proceed. 



Validating 



S3.Validate_ 
RoutingConfirn 
(addr, status) 




(Incomplete) 



(Complete) 



Optionally the information received 
from the Services functional layer 
may be used to generate a further 
request to validate and perform 
routing analysis and translation, as 
required to enable the call to 
proceed. The information used to 
generate the request may be derived , 
from the response received from the 
Services functional layer as well as 
the information received from the 
Call Control functional layer in this 
functional grouping. 

NOTE : This may involve the Services 
functional layer entity acting as a 
proxy and sending the request to any 
number of functional entities in the 
Services functional layer. It may also 
involve the Service Control functional 
layer issuing requests to a number of 
functional entities in the Services 
functional layer (like presented here). 

The order or sequence of such 
requests is outside the scope of 
the TIPHONTS-02.003. 



S3.Validate_ 
RoutingReject x 



SC3 .AccessAnd 
RoutingReject 



Null 



Rejects the Access routing request when 
1 — i number does not result in a reference to 
another network or another service. 



Figure A.14: Originating Gateway: Generic call routing 





S3.AccessRoutirj 
Confirm 
(addr) 



S3.AccessRoutincK 
Request / 
(addr) / 



Valid address, query 
Number portability DB 



SC3.AccessAnc 
RoutingConfirm 
(addr) 




Null 



Confirm that Routing has been chosen 
-J and pass the Routing information 
' to the Call Control functional layer. 



Figure A.15: Originating Gateway: Call routing for number portability 
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Null 



C3.CallAncL 

BearerRequest 

(addr) 



SC3.AccessAnd^ 
RoutingRequest 
(addr) 
via sc3 



Requests that the Service Control functional layer provides Access and 
i Routing response information. This determines whether the call should 
proceed and if so to what destination it should be offered. 



Originating 
Routing 



SC3.AccessAnd/ 
RoutingConfim 
(addr) 




Request that the Bearer Control 
functional layer in this domain 
obtains the bearer requirements 
for the call. 



SC3.AccessAn< 
RoutingReject 




C3.CallReport._ 
Address_ 
Incomplete 
x viaC3 



Transfer the rejection to 
] the SCN domain. 



(confirm) 



(Reject) 



C2.Call Request 

(addr) 

via C2 



Ori ginating 
OverlapReceiving 



Send the Call Request 
"1 to the next domain. 




store := addr; 
SET(Tx2); 



Originating_ j 
OverlapSending 



The Digits already received in 
^ the Call request is stored in CC. 
Start additional information 
timer Tx2. 



Figure A.16: Originating Gateway: Initiating a call 



Originating 
OverlapSending 



C3. Additional I 
Indication 
(addr) 



Info 



RESET(Tx2) 



i Cancel timer Tx2. 



addr := store // addr; 
RESET(Tx2); 



SC3.AccessAnd^ 

RoutingRequest 

(addr) 

via sc3 / 



The already received digits are sent 
together with the additional ones. This 
determines whether the call should 
proceed and if so to what destination it 
should be offered. 



Requests that the Service Control 
i functional layer provides Access 
and Routing response information. 



Originating 
Routing 



Figure A.17: Originating Gateway: Overlap sending 
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Originating 
Overlap_ 
Receiving 



C2.Call Report.. 
Addresslncomptete 



C3.Additionallnf 
> Indication 
(addr) 



C3.CallReport, 

Address_ 

Incomplete 



RESET(Tx3) 



i Stops timer Tx3. 



SET(Tx3) 



Originating 
Overlap_ 
Receiving 



Starts timer Tx3 in order to 
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Figure A.18: Originating Gateway: Overlap receiving towards next functional grouping 
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Figure A.19: Originating Gateway: Completing the address 
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Figure A.20: Originating Gateway: Remote user has been alerted 
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Figure A.21 : Originating Gateway: Activating the call 
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Sends release to the Call Control 
functional layer in the next domain. 




i Sends release to the SCN. 



Sends a request to release bearer to the 
Bearer Control functional layer in this 
functional grouping. 



Figure A.22: Originating Gateway: Releasing the call 



A.2.1 .4 The Bearer control functional layer 
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Figure A.23: Originating Gateway: Reserving a bearer 
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Figure A.24: Originating Gateway: Establishing a bearer 
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Figure A.25: Originating Gateway: Activating a bearer 
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Figure A.26: Originating Gateway: Releasing a bearer 



1 .5 The Media Control functional layer 



Media_ 
Null 



Media_ 
Reserving 




, T3.TransportR3V_ 
Confirm 



'MCOO' 



Determine the media and the IP 
Transport plane capabilities. 



'MC0T 



T3.TransportRs|/ 
Request 



N3.MediaRsv_ 
Confirm 



\ Confirm the media and transport options 
i to the Bearer Control functional layer 
I of this FG 



Media_ 
Reserving 



Media_ 
Reserved 



Figure A.27: Originating Gateway: Reserving media 
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Figure A.28: Originating Gateway: Establishing media 
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Figure A.29: Originating Gateway: Activating media 
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Figure A.30: Originating Gateway: Releasing media 



A.2.1 .6 The IP Transport plane 



The functional model and the functional entity actions of the IP Transport plane are outside the scope of the present 
document. 



A.2.2 Originating Terminal FG 



The Originating terminal functional grouping implements the Terminal. The figure A. 31 shows the information flow 
within the Terminal and the information flow to the next functional grouping (e.g. a network functional grouping) on 
the originating side of the call. 
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Figure A.31 : Information flows at the Originating Terminal Functional Grouping 
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Figure A.32: Information flows at the Originating Terminal Functional Grouping during the call-setup 

phase 

NOTE 1 : The sender of the Bearer request shall be prepared to receive media as soon as the Bearer request is 
transmitted. 

NOTE 2: The CI. CallReport Addresslncomplete and the Cl.AdditionallnfoIndication may be repeated. 

The user indicates, by means of an implementation dependent interface, that the call shall be cleared. The User/Service 
control interface requests the call to be cleared. The Originating terminal functional grouping indicates clearing of the 
call to the Next functional grouping. The bearer is internally cleared. 
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The Originating terminal functional grouping receives from the Next functional grouping an indication that the called 
party has cleared. The Originating terminal functional grouping clears the bearer internally before the user is informed 
about the clearing of the call. 

A.2.2.1 Service functional layer 

The services available to the terminal user are outside the scope of the present document. 

A.2.2.2 The Service Control functional layer 
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Figure A.33: Originating Terminal: Decide if terminal status and the service profile allows placing the 

call 
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A.2.2.3 The Call Control functional layer 
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Figure A.34: Originating Terminal: Initiating a call 
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Figure A.35: Originating Terminal: overlap sending to the next functional grouping 
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Figure A.36: Originating Terminal: completing the address 




Figure A.37: Originating Terminal: Call received (remote user alerting) 
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Figure A.38: Originating Terminal: activating a call 
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Figure A.39: Originating Terminal: releasing a call 
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A.2.2.4 The Bearer control functional layer 
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Figure A.40: Originating Terminal: reserving a bearer 
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Figure A.41: Originating Terminal: establishing a bearer 



ETSI 



80 



ETSI TS 101 314 V1.1.1 (2000-09) 



Bearer_ 
Established 



BearerAct_ 
Indication 




N1.MediaAct_ 
Indication 



i Inform media control(s) in this functional 
; grouping that the call is established 



Bearer_ 
Active 



Figure A.42: Originating Terminal: activating a bearer 
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Figure A.43: Originating Terminal: releasing a bearer 
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A.2.2.5 The Media Control functional layer 
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Figure A.44: Originating Terminal: reserving media 
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Figure A.45: Originating Terminal: establishing media 
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Figure A.46: Originating Terminal: activating media 
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Figure A.47: Originating Terminal: releasing media 



A.2.2.6 IP Transport plane 



The functional model and the functional entity actions of the IP Transport plane are outside the scope of the present 
document. 



A.2.3 Network Functional Groupings 



The network functional grouping receives a call request and a bearer request from the previous functional grouping. The 
network functional grouping shall co-ordinate the reception of the call request with the reception of the bearer request. 

The received called party number does not (when analysed in the Service functional layer) result in a destination, thus 
the network functional grouping returns a report to the previous functional grouping and waits for additional digits 
before any routing can take place (Overlap sending phase). Once additional information is received (one or more digits) 
the network functional grouping can route the call to the next functional grouping (Overlap receiving phase). The 
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network functional grouping shall supervise the Overlap sending and the Overlap receiving phase. The next functional 
grouping reports when the Called party number is complete and establishment of the bearer can take place. 

User dependent events (Alerting) are reported by the next functional grouping and transferred to the previous functional 
grouping. Once the user answers the call (Active phase) the Call request is confirmed by the next functional grouping 
and transferred to the previous functional grouping. 

The figure below show the detailed information flow required for a basic call setup. 
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Figure A.48: Information Flows at the Originating Network Functional Grouping during call setup flow 



NOTE: The Cn.CallReportAddressIncomplete and the Cn.AdditionallnfoIndication may be repeated. The 
previous functional grouping sends an indication when the Calling party clears. The indication is 
transferred to the next functional grouping and the bearer is cleared internally. The network functional 
grouping receives an indication from the next functional grouping when the Called party clears. The 
indication is transferred to the previous functional grouping and the bearer is internally cleared. 
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The figure below shows the detailed information flows required for call termination. 
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Figure A.49: Information Flows at an Originating Network Functional Grouping during call teardown 

phase 
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Figure A.50: Information Flows at the Intermediate Network Functional Grouping during call setup 

time 

NOTE 1 : The C2.CallReportAddressIncomplete and the C2. Additionallnfolndication may be repeated. 
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Figure A.51 : Information Flows at an Intermediate Network Functional Grouping during call teardown 

phase 
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Figure A.52: Information flows at the Terminating Network Functional Grouping during call setup 



NOTE 2: The Cn.CallReportAddressIncomplete and the Cn. Additionallnfolndication may be repeated. 
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Figure A.53: Information Flows at a Terminating Network Functional Grouping during call tear down 

phase 
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NOTE: This clause includes SDL diagrams describing only the Originating Network Functional Grouping. The 

terminating and intermediate network functional groupings act identically at this abstraction level, so they 
are left out. 



A.2.3.1 The Services functional layer 

The behaviour of the Services functional layer is implementation dependent. The Services functional layer is expected 
to respond to requests made from the Service Control functional layer with appropriate parameters. 



A.2.3.2 The Service Control functional layer 



Idle 



SC2.AccessAn<Jl_ 
> RoutingRequest 
(addr) 




False 



True 



S2.User_ 

RoutingRequest 

(addr) 



Requests the user profile 
to apply caller-specific 
routing 



3outing_by_ 
A_User_ 
Profile 



S2.User_ 

RoutingConfirm< 

(addr) 



S2.User_ 
RoutingReject 




Rejects the Access routing 
SC2.AccessAnd_ 'request when number does 
RoutingReject , not result in a reference to 

i another network or another service. 



Idle 



Figure A.54: Network: Call routing according to the caller's user profile is done by Originating 

Network only 
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( Validate_ 
Routing 



S3.ValidateRouting 
Request(addr) , 



Requests the Services functional layer 
, _ 'to validate and perform routing analysis 
~] and translation, as required to enable 
ithe call to proceed. 



Validating 




(Incomplete) 



(Complete) 



Optionally the information received 
from the Services functional layer 
may be used to generate a further 
request to validate and perform 
routing analysis and translation, as 
required to enable the call to 
proceed. The information used to 
generate the request may be derived , 
from the response received from the 
Services functional layer as well as 
the information received from the 
Call Control functional layer in this 
functional grouping. 

NOTE : This may involve the Services 
functional layer entity acting as a 
proxy and sending the request to any 
number of functional entities in the 
Services functional layer. It may also 
involve the Service Control functional 
layer issuing requests to a number of 
functional entities in the Services 
functional layer (like presented here). 

The order or sequence of such 
requests is outside the scope of 
the TIPHONTS-02.003. 



S3.Validate_ 
RoutingReject 



SC2.AccessAn4 
RoutingReject 



Null 



Rejects the Access routing request 
when number does not result in a 
reference to another network or 
another service. 



Figure A.55: Network: Generic call routing 
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SC2.AccessAn 
RoutingReject 



Idle 



Rejects the Access routing 
request when number does 
not result in a reference to 
another network or another service. 



Figure A.56: Network: Call routing according to the callee's user profile by Terminating Network only 
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(addr) 



, _ 1 Valid address, query 
~] Number portability DB 
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Routing 
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SC2.AccessAncl 
RoutingConfirm 
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i Confirm that Routing has been chosen 
-i and pass the Routing information 
to the Call Control functional layer. 



Idle 



Figure A.57: Network: Call routing by number portability database 
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Null 



, d.CallReques: 
(addr) 



SC2.AccessAnd_ 
RoutingRequest 
(addr) 
via sC1 



Requests that the Service Control functional layer provides Access and 
Routing response information. This determines whether the call should 
proceed and if so to what destination it should be offered. 



Routing 




C2.CallRequest 
(addr) 
via C2 



Request that the Bearer Control 
J functional layer in this functional 
grouping obtains the bearer 
l require me ntsjqr the cajl. 



Reject 



Send the Call Request 
1 to the next functional 
grouping 




SC2.AccessAnd 
RoutingReject 



C1.CallReport._ 
Address_ 
Incomplete 
,viaC1 



Transfer the rejection to 
the previous functional 
grouping 



The Digits already received in 
store := addr; _ j the Call request is stored in CC. 
SET(Tx2); 1 Start additional information 

timer Tx2. 



[Overlap_ 
Receiving 



Null 



bverlap_ 
ISending 



Figure A.58: Network: Initiating a call 



Request that the Bearer Control functional layer 
i in this funtional group obtains the bearer 
requirements for the call. 



Bearer Rsv 
Request 



Wait 




Figure A.59: Network: Procedure BearerReserve 
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addr := store // addr 



SC2.AocessAnd2 
RoutingRequest 
(addr) 
via sC1 



- Cancel timer Tx2. 



The already received digits are sent 
together with the additional ones. This 
determines whether the call should 
proceed and if so to what destination it 
should be offered. 



Requests that the 
-i Service Control functional layer provides 
Access and Routing response information. 



Routing 



|Overlap_ 
piece iving 



Figure A.60: Network: Overlap sending 



C2.Call Report. 
Add ress I n co mpTele 



C1 .Additional Info. 
> Indication 
(addr) 



C1 .Address_ 
Incomplete 



RESET(Tx3) 



- - Stops timer Tx3. 



SET(Tx3) 



foverlap_ 
peceving 



Starts timer Tx3 in order to 
i supervise the reception of 
additional digits. 



C2.Additionallnfo2 

Indication 

(addr) via C2 / 



Transfer additional digits to the next 
functional grouping 



SET(Tx3) 



- - Starts timer Tx3. 



|Overlap_ 
peceving 



Figure A.61 : Network: Overlap receiving between previous and next functional grouping 
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>Tx3 



C2.Call Report, 
AddressComplel 



C1 .CallReport.. 
AddressComplejte 
viaC1 



Timer Tx3 expires. The CC initiates a 
report to previous FG that the number 
from now on is regarded as complete. 



RESET(Tx3) 



i Stop timer Tx3 (if running). 




C1 .CallReport._ , Send the report to previous FG 
AddressComplete n if not already sent due to timer 
viaC1 Tx3 expiry (see CC07). 



CalL 
Present 




Figure A.62: Network: Completing the address 
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C2.Call Report.. 
AddressCompleh 




C2.Call Report.. 
Alerting 



C2.CallComplete 



Do not send a report via C1 as 
n it has already been sent due to 
timer Tx3 expiry (see CC07) 



Bearer_ 
Establish 




CLCallReport, 

Alerting 

viaC1 



1 Indicate to the previous FG 
~] that the called user is now alerting. 



CalL 
Received 



Figure A.63: Network: Call received (remote user alerting) 
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Figure A.64: Network: Procedure BearerEstablish 



CalL 
Received 




C2.CallConfirm< 



Bearer_ 
Establish 



Bearer_ 
Activate 



CLCallConfirm 
viaC1 



Indicate that the call has been answered 
\ to the Bearer Control functional layer 
' ~j in this functional grouping and 
to the Call Control functional layer in 
the previous functional grouping. 



CalL 
Active 



Figure A.65: Network: Call activated 



Bearer Act_ 
Indication 




Send BearerActlndication to the Bearer 
'Control functional layer in this functional 

grouping to indicate that the bearer should 
^ be fully established as a twcM/vay flowr 



Figure A.66: Network: Procedure BearerActivate 
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CalL 
Active 



, C1.Release_ 
Indication 



C2.Release_ 
Indication 



C2.Release_ 
Indication 
via C2 



Bearer_ 
Release 



Sends release to the Call Control 
functional layer in the next 
functional grouping 



C1 .Release_ 

Indication 

viaC1 



1 Send release to the previous 
^functional grouping. 



Send a request to release bearer to the Bearer 
Control functional layer in this functional grouping 



Null 



Figure A.67: Network: Releasing a call 




Figure A.68: Network: Procedure BearerActivate 
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2.3.4 The Bearer Control functional layer 



Bearer_ 
Idle 



Bearer Rsv_ 
Request 



C1 .Bearer_ 
Request 



SET(Tx2) 



If a Bearer Request has not 
been received from the Call Control 
] functional layer in this functional layer 
then start Timer Tx2 



Bearer_ 
Reserving. 1 



C1 .Bearer 
> Request 
(brq) 



Tx2 



RESET(Tx2) 




After Bearer Request is received, 
stop timer Tx2. 



Compare the requirements of the Bearer Request 
from the Bearer Control functional layer in the previous 
] network and the BearerRsvRequest from the Call Control 
^functionaMayer of this terminal to ensure consistency. 



(Consistent) 



N2.MediaRsv_ 
Request 



Bearer_ 
Reserving.2 



If bearer requests are consistent, then 
request that the Media Control functional 
layer of this terminal identifies the media 
^options for the call. 



(Inconsistent) 



Bearer Rsv_ 
Reject 



Bearerldle 



Figure A.69: Network: Reserving a bearer: waiting for BearerRequest 

Grouping 



from previous Functional 
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Bearer_ 
Reserving.2 







\N2.Media_ 
/ RsvConfirm 






BearerRsv 
Confirm 









C2.BearerRequest 

via C2 / 



Report the bearer requirements and media 
'options for the call to the Call Control 
~] functional layer in this functional grouping. 



Send the bearer requirements and media 
\ options towards the next functional grouping 



Bearer_ 
Reserved 



Figure A.70: Network: Reserving a bearer: waiting for MediaRsvConfirms from Media Control 

functional entity 



C1 .Bearer 
Confirm 
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\N2.MediaEst_ 
' Confirm 


/ ■ / 



N2.MediaEst_ 
Request 



Report the chosen media options to 
'the Media Control functional layer 
~] in this functional grouping, 



Bearer_ 
Establishing 



BearerEst. 
Indication 


y 






/ C1.Bearer_ 
\ Confirm 
\ viaC1 



Confirm bearer establishment to 
' the Call Control functional layer 
~] in this functional grouping. 



Confirm bearer establishment to 
^the previous functional grouping. 



Bearer_ 
Established 



Figure A.71 : Network: Establishing a bearer 
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Inform media control(s) in this functional 
^grouping that the call is established 
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Figure A.72: Network: Activating a bearer 
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BearerEstablished, 
BearerActive, 



BearerRelease^ 
Request 



BearerReserved 



Bearer_ 
Releasing 



> N2.Media_ 
ReleaseConfirm 



N2.Media_ 
ReleaseRequesjt 



Sends release request to Media control 
functional layer in this functional 
, grouping. 



BearerRelease_ 
Confirm 



Confirms the bearer release to the Call 
Control functional layer in this functional 
, grouping. 



Bearer_ 
Releasing 



Bearer_ 
Idle 



Figure A.73: Network: Releasing a bearer 



A.2.3.5 The Media Control functional layer 
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N2.MediaRsv^ 
Request 



\T2.TransportRsv_ 
^Confirm 



'MC00' 



Determine the media and the IP 
^Transport plane capabilities. 



'MC01' 



Confirm the media and transport options 
to the Bearer Control functional layer 
"I of this FG 



T2.TransportRsv 
Request 



N2.MediaRsv_ 
Confirm 



Media_ 
Reserving 
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Figure A.74: Network: Reserving media 
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Media_ 
Reserved 



N2.MediaEst_ 
Request 




'MC02' 



Requests that the IP Transport plane 
implements the media requirements. 
~] Requests that the IP Transport plane 
provides an adequate QoS, based on 
the QoS requirements for the call. 



T2.TransportEs1. 
Request 



Media_ 
Establishing 



Media_ 
Establishing 




Confirm establishment of the media 
connection to the Bearer Control 
functional layer of this functional 
grouping, two way communications 
may be available at this point. 

NOTE: If the next functional grouping is a 
terminal the speech may be established 
only in the direction of the caller. 



Figure A.75: Network: Establishing media 
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N2.MediaAct 
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Inform the transport functional layer 
'MC04' - -| tnat tne ca " is established. Two way 

i communications shall be established at 
i this point if it were not done earlier. 



T2.TransportAcl_ 
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Media_ 
Activated 



Figure A.76: Network: Activating media 



ETSI 



99 



ETSI TS 101 314 V1.1.1 (2000-09) 



Media_ 
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N2.Media_ / 




\x T2. Transport^ 




Release_ 




/Release_ 




Request 




/ Confirm 
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Requests that the IP Transport plane 




Confirm termination of the media flow 


'MC05' 


- ^terminates the media flow 


'MC06' 


- -]to Bearer Control functional layer 











T2. Transport^ 
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Request 



N2.MediaRelease^ 
Confirm , 



Media 



Media_ 
Null 



Figure A.77: Network: Releasing media 

A.2.3.6 The IP Transport plane 

The functional model and the functional entity actions of the IP Transport plane are outside the scope of the present 
document. 
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A.2.4 Terminating Gateway Functional Grouping 

The Terminating Gateway Functional Grouping receives a call request and a bearer request from the previous functional 
grouping. The previous network functional grouping shall co-ordinate the reception of the call request with the 
reception of the bearer request. 
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Figure A.78: Information flows at the Terminating Gateway Functional Grouping during call setup 

phase 

NOTE 1: The Cn.CallReportAddressIncomplete and the Cn.AdditionallnfoIndication may be repeated. 

The received called party number does not (when analysed in the Service functional layer) result in a destination, thus 
the Terminating Gateway Functional Grouping returns a report to the previous functional grouping and waits for 
additional digits before any routing can take place (Overlap sending phase). Once additional information is received 
(one or more digits) the Terminating Gateway Functional Grouping shall route the call to the SCN (Overlap receiving 
phase). The Terminating Gateway Functional Grouping shall supervise the Overlap sending and the Overlap receiving 
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phase. The Terminating Gateway Functional Grouping reports when the Called party number is complete and 
establishment of the bearer can take place. 

User dependent events (Alerting) are reported by the SCN and Terminating Gateway Functional Grouping transfers 
them to the previous functional grouping. Once the user answers the call (Active phase) the Call request is confirmed by 
the SCN and Terminating Gateway Functional Grouping transfers confirmation to the previous functional grouping. 

The figure A.78 shows the detailed information flow required for a basic call setup. 

The Terminating Gateway Functional Grouping receives an indication from the previous functional grouping when the 
Calling party clears. The indication is transferred to the next functional grouping and the bearer is internally cleared. 



MSC Call_Release_in_Terminating_Gateway 



ACTIVE_PHASE 



C2.Release_ 
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C3.Release_ 
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C2.Release_ 
Indication 



C3.Release_ 
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T3.Transport_ 
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N3.Media_ 
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T3. Transport 
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N3.Media_ 
ReleaseConfirm 
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Confirm 



Figure A.79: Information flows at the Terminating Gateway Functional Grouping during call teardown 

The Terminating Gateway Functional Grouping receives an indication from the next functional grouping when the 
Called party clears. The indication is transferred to the previous functional grouping and the bearer is internally cleared. 

A.2.4.1 Service functional layer 

The behaviour of the Services functional layer is implementation dependent. The Service functional layer is expected to 
respond to requests made from the Service Control functional layer with appropriate parameters. 
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Null 



SC3 AccessAnd ' Rec l uests tne Services functional layer 

X Rout'ingRequest - n to * a , lidat ? f d P erform J"** ana 'y sis 
'/arWrt H and translation, as required to enable 

[aaar > i the call to proceed. 



S3.ValidateRouting 
Request(addr) 



Validating 



S3.Validate_ 
RoutingConfirn 
(addr, status) 




(Incomplete) 



(Complete) 



Optionally the information received 
from the Services functional layer 
may be used to generate a further 
request to validate and perform 
routing analysis and translation, as 
required to enable the call to 
proceed. The information used to 
generate the request may be derived < 
from the response received from the 
Services functional layer as well as 
the information received from the 
Call Control functional layer in this 
functional grouping. 

NOTE : This may involve the Services I 
functional layer entity acting as a 
proxy and sending the request to any 
number of functional entities in the 
Services functional layer. It may also 
involve the Service Control functional 
layer issuing requests to a number of 
functional entities in the Services 
functional layer (like presented here). 

The order or sequence of such 
requests is outside the scope of 
the TIPHONTS-02.003. 



S3.Validate_ 
RoutingReject x 



SC3.AccessAncL 
RoutingReject 



Rejects the Access routing request when 
n number does not result in a reference to 
another network or another service. 



Null 



Figure A.80: Terminating Gateway: Generic call routing 
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S3.AccessRouti 
Confirm 
(addr) 



S3.AccessRouting 

Request 

(addr) 



Valid address, query 
Number portability DB 



SC3 .AccessAnd 

RoutingConfirm 

(addr) 



Confirm that Routing has been chosen 
i and pass the Routing information 
to the Call Control functional layer. 



Access_ 
Routing 



Null 



Figure A.81 : Terminating Gateway: Call routing with number portability database 
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Null 



C2.Call Request, 
(addr) 



SC3.AccessAnd_ 
RoutingRequest 
(addr) 



Requests Service Control to provide 
1 Access and Routing response 
"] information. This determines whether 
the call should proceed and if so to 
what destination it should be offered. 



Terminating_ 
Routing 



SC3.AccessAnd z 
RoutingConfirn 
(addr) 



(Confirm) 



SC3.AccessAnd/ 
RoutingReject \ 




Request that the Bearer Control 
1 functional layer in this functional^ 
i grouping obtains the bearer \ 
i_ r eq u]re me nts for the call . 



(Reject) 



;C3.CallAndD_D 
BearerRequest 
via C3 



Terminating_ 
Overlap_ 
Receiving 



Send the Call Request 
to theSCN. 




C2.CallReport._ 
Address_ 
Incomplete 

x via C2 



store := addr 



SET(Tx2) 



Terminating_ 
Overlap_ 
Sending 



. Transfer the rejection to the 
previous functional grouping. 



The Digits already received 
in the Call request is 
stored in CC. 



Start timer Tx2 to supervise 
the reception of additional 
information. 



Figure A.82: Terminating Gateway: Initiating a call 
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Terminating_ \ 
Overlap_ 
Sending 



C2. Additional 
> Info Indication 
(addr) 



RESET(Tx2) 



SC3.AccessAnd^ 

RoutingRequest 

(addr) 

via sc3 / 



Stops timer Tx2. 



addr := store // addr - The already received digits are sent again. 



Requests that the Service Control functional 
layer provides Access and Routing response 
information. 



Terminating 
Routing 



Figure A.83: Terminating Gateway: Overlap sending 
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C3.Call Report. 
Addresslncomplete 



C2.Additionallnfo. 
indication 
(addr) 



C2.Address 
Incomplete 




RESET(Tx3) 



Starts timer Tx3 in order to C3.Additionallnfo_ 
supervise the reception of Indication 
additional digits. (addr) via C3 / 



SET(Tx3) 



Terminating 
Overlap_ 
Receiving 



Stops timer Tx3. 



Sends additional digits to SCN. 



Srarts timer Tx3 



Figure A.84: Terminating Gateway: Overlap receiving - relaying additional address information 

towards SCN 
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Terminating_ 
Overlap_ 
Sending 



:Tx3 



C3.CallReport._ 
AddressComplete 
via C3 



/ [Terminating_ 
CalL 
Proceeding 



Timer Tx3 expires. 



The CC initiates a report to 
previous functional grouping 
that the number from now on 
is regarded as complete. 



C3.CallReport. / 
AddressComplete 



RESET(Tx3) 



C2.CallReport._ 
AddressComplete 
viaC2 



Stop timer Tx3. 



Send the report via C2 



C3.CallReport._ 
AddressCompleft 



Do not send a report via C3 as ; Terminating_ 
it has already been sent due to I Call 
timer Tx3 expiry. \ Proceeding 



Figure A.85: Terminating Gateway: Address is complete, call will proceed 
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via C2 1 is now alerting. 
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Terminating_ 
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Figure A.86: Terminating Gateway: Call is received, remote user is alerting 
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C3.CallAnd_ , 
Bearer Confirm 




Bearer_ 
Activate 



Indicate that the call has been answered 
\ _] to the Bearer Control functional layer 
in this functional grouping and to the 
previous functional grouping. 



C2.CallAndBeaie(_ 
Confirm 
viaC2 




Figure A.87: Terminating Gateway: Completing the call 




, C3.Release_ 
Indication 



C2.Release_ 
Indication 



Sends release to the Call Control 
functional layer in the next domain. 



C2.Release_ 

Indication 

viaC2 




Bearer_ 
Release 



i Sends release to the SCN . 



Sends a request to release bearer to the 
i Bearer Control functional layer in this 
functional grouping. 



Null 



Figure A.88: Terminating Gateway: Releasing the call 
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A.2.4.4 Bearer Control functional layer 



Bearerldle 



Bearer Rsv_ 

Request._ 

Terminating 



C2.Bearer_ 
Request 



SET(Tx2) 



If a Bearer Request has not 
been received from the Call Control 
functional layer in this functional layer 
then start Timer Tx2 



Terminating_ 

Bearer_ 
Reserving. 1 



C2.Bearer_ 
> Request 
(brq) 



>Tx2 



RESET(Tx2) 



After Bearer Request is received, 
stop timer Tx2. 




Compare the requirements of the Bearer Request 
from the Bearer Control functional layer in the previous 
network and the BearerRsvRequest from the Call Control 

^functionaMayer of this terminal to ensure consistency. 



(Consistent) 



(Inconsistent) 



N3.MediaRsv_ 
Request 



If bearer requests are consistent, then 
request that the Media Control functional 
layer of this terminal identifies the media 
options for the call. 



Bearer Rsv_ 
Reject 



Terminating_ 

Bearer_ 
Reserving. 2 



Bearerldle 



Figure A.89: Terminating Gateway: Reserving a bearer: waiting for BearerRequest from previous 

functional grouping 
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Reserving. 2 



> N3.Media_ 
RsvConfi rm 



BearerRsv \ ! Report the bearer requirements and media 

Confirm ~~ / n options for the call to the Call Control 
/ | functional layer in this domain. 

Terminating_ 
I Bearer_ I 
Reserved 

Figure A.90: Terminating Gateway: Confirming bearer reservation 
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/ \ 
Terminating_ 
Bearer_ 
Reserved 







Bearer Est 
Request 








/ N3.MediaEst_ 
\ Request 







Terminating_ 

Bearer_ 
Establishing 



Report to the Media Control functional 
i layer in this functional grouping the 
chosen media options. 



Terminating_ 

Bearer_ 
Establishing 



> N3.MediaEst_ 
Confirm 



C2.Bearer_ 

Confirm 

viaC2 



BearerEst_ 
Confirm 



Bearer_ 
Established 



Report the media is established to the 
Call Control functional layer of this terminal. 
The media stream may be one-way or 
two-way at this stage depending on 
implementation options. 

Note that the network may choose not to 
permit conveyance of two-way speech flows. 



Figure A.91: Terminating Gateway: Establishing a bearer 
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Bearer Act 
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/ N3.MediaAct_ 
\ Indication 



Inform media control(s) in this functional 
^grouping that the call is established 



Bearer_ 
Active 



Figure A.92: Terminating Gateway: Activating a bearer 
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BearerActive, ) TerminatingBearerReserved 



BearerRelease^ 
Request 



N3.Media_ 
ReleaseRequesjt 



Sends release request to Media control 
i functional layer in this functional 
grouping. 




BearerRelease_ 
Confirm 



Confirms the bearer release to the Call 
i Control functional layer in this functional 
grouping. 



Bearer_ 
Releasing 



Bearer_ 
Idle 



Figure A.93: Terminating Gateway: Releasing a bearer 
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A.2.4.5 Media control functional layer 



Media_ 
Null 



Media_ 
Reserving 



N3.MediaRsv^ 
Request 



jT3.TransportRsv_ 
Confirm 



'MC00' 



Determine the media and the IP 
^Transport plane capabilities. 



'MC01' 




N3.MediaRsv_ 
Confirm 



Confirm the media and transport options 
nito the Bearer Control functional layer 
M of this FG 




Figure A.94: Terminating Gateway: Reserving media 
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Establishing 



N3.MediaEst_ 
Request 




J3.TransportEst 
Confirm 




Requests that the IP Transport plane 
1 implements the media requirements. 
~] Requests that the IP Transport plane 
provides an adequate QoS, based on the 
QoS requirements for the call. 



T3.TransportEsl_ 
Request 



'MC03' 



N3.MediaEst_ 
Confirm 



Confirm establishment of the media 
connection to the Bearer Control 
^functional layer of this functional 
grouping, two way communications 
may be available at this point. 



Media_ 
Establishing 



Media_ 
Established 



Figure A.95: Terminating Gateway: Establishing media 
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Media_ 
Established 



N3.MediaAct_ 
Indication 



'MC04' 



Inform the transport functional layer 
_] that the call is established. Two way 

communications shall be established at 
^thjs point if it were not done earlier L 



T3.TransportAcl_ 
Indication 



Media_ 
Activated 



Figure A.96: Terminating Gateway: Activating media 
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Release_ 
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^\ T3.Transport_ 
/Release_ 
/ Confirm 








'MC05' 


1 Requests that the IP Transport plane 
^terminates the media flow 


'MC06' 



Confirm termination of the media flow t 
] Bearer Control functional layer 



T3. Transport 

Release_ 

Request 



N3.MediaRelease_ 
Confirm 



Media_ 
Releasing 



Media_ 
Null 



Figure A.97: Terminating Gateway: Releasing media 



A.2.4.6 IP Transport plane 



The functional model and the functional entity actions of the IP Transport plane are outside the scope of the present 
document. 
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A.2.5 Terminating Terminal FG 

The Terminating terminal functional grouping receives a call request and a bearer request from the previous functional 
grouping. The Terminating terminal functional grouping shall co-ordinate the reception of the call request with the 
reception of the bearer request. 

The Service Control functional layer shall co-ordinate the requested service (audio, video, etc.) with the availability of 
the hardware devices with the called user requirements required to perform the service. 

NOTE: The interface for how the User impacts the selection of the hardware device is implementation dependent. 

The arrival of the call is indicated to the Services functional layer (and thus the user) and reported to the previous 
functional grouping as an Alerting event. The Services functional layer shall indicate when the user answers and the call 
request may be confirmed to the previous functional grouping. 

The figure A.98 shows the detailed information flow required for a basic call setup. 
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Figure A.98: Information flows at the Terminating Terminal Functional Grouping during the call setup 

phase 

The previous functional grouping shall indicate when the Calling party clears. The bearer shall be released internally 
before an indication is sent to the Services functional layer. The Services functional layer shall indicate to the user that 
the call is cleared. The indication to the user is implementation dependent. 

The figure shows the detailed information flow required when the Calling party clears. 
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Ul. Release 
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N1. Media 
ReleaseRequest 
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T1. Transport 
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N1 .Media 
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Figure A.99: Information flows at the Terminating Terminal Functional Grouping during the call 

teardown phase 

The Terminating terminal functional grouping shall indicate to the previous functional grouping when the Called party 
clears and internally release the bearer. 



A.2.5.1 The Services functional layers 

The services available to the terminal user are outside the scope of the present document. 
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.5.2 The Service Control functional layer 



Registered 



^Cl .0_Service . 
' Request 



S1 .0_Service_ 
Request 



Forward the service 
request to the service 
profile when registered 



Originating 
Wait 



Registered 



> SC1 .T_Service_ 
Request 



S1 T_Service_ 
Request 



Forward the service 
request to the service 
profile when registered 



Terminating 
Wait 




Figure A.100: Terminating Terminal: Decide if terminal status and the service profile allows 

presenting the call to the user 
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Null 



CLCallRequest 



Indicates the arrival of a call to the 
associated Service Control layer 
Functions. A decision is made that the 
call will be allowed to proceed based on 
user preferences and terminal/user state 



Request that the Bearer Control 
functional layer in this functional 
grouping obtains the bearer require 
ments for the call. 



Indicates arrival of 
call to the user 



Optionally, the Call Control 
Functional layer may send 
also CI.CallReport.Alerting 
primitive to previous FG 




Decide if the registration status 
i and terminal status requires 
call control to reject the call. 



Figure A.101: Terminating Terminal: initiating a call 



Bearer Rsv_ 
Request._ 
Terminating 
(brr) 



Request that the Bearer Control functional layer 
in this funtional group obtains the bearer 
requirements for the call. 



Wait 




Figure A.102: Terminating Terminal: Procedure T BearerReserve 
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T_Bearer_ 
Establish 



CalL 
Alerting 



Figure A.103: Terminating Terminal: User alerting 



\ i Request that the Bearer Control functional layer 
BearerEst_ \ _ _] in this functional group establishes the bearer. 
Request(ber) / , The bearer can be unidirectinal or bidirectional, 
/ ^depending on implementation options^ 



Wait 



Bearer Est_ 
Confirm 




Figure A.104: Terminating Terminal: Procedure T BearerEstablish 
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Send Call Confirm to the Call Control 
functional layer in the previous functional 
grouping. 



Optionally, the bearer can 
n be established before sending 
CallConfirm 



Send BearerActlndication to 
the Bearer Control functional layer in this 
functional grouping to indicate that the 
bearer should be fully established as a 
two-way flow. 



Indicates the establishment 
n of a call to the user. 



Figure A.105: Terminating Terminal: Accepting a call 




Send an optional BearerActlndication 
to the Bearer Control functional layer 
i in this functional grouping to indicate 
that the bearer should be fully 
established as a two-way flow. 




Figure A.106: Terminating Terminal: Procedure Bearer Activate 
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CalL 
Active, 



CallPresent, OverlapReceiving, 
AddressComplete, CallAlerting 



C1 .Release_ 
Indication 



\UI.Release_ 
Request 



'CC15' 



UI.Release_ 
Indication 



'CC08' 





C1 .Release_ 

Indication 

viaC1 



Bearer_ 
Release 



_ 




Sends release to the Call Control 
functional layer in the next/previous 
functional grouping. 



Sends the BearerReleaseRequest 
to the Bearer Control functional 
layer in this functional grouping 
in order to to cease the media flows. 



UI.Release_ , Confirm to the user oand/or 
Complete_ - n associated Service Control functions 
Indication 1 that the call is released 



Null 



Figure A.107: Terminating Terminal: Releasing a call 



A.2.5.4 The Bearer Control functional layer 



Bearerldle 



Bearerldle 



Bearer Rsv_ 

Request._ 

Terminating 



C1 .Bearer_ 
Request 



SET(Tx2) 



If a Bearer Request has not 
been received from the Call Control 
functional layer in this functional layer 
then start Timer Tx2 



Terminating_ 

Bearer_ 
Reserving. 1 



Figure A.108: Terminating Terminal: Reserving a bearer: waiting for BearerRequest from previous 

Functional Grouping 
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Terminating_ 

Bearer_ 
Reserving. 1 



C1 .Bearer_ 
> Request 
(brq) 




•>Tx2 



After Bearer Request is received, 
stop timer Tx2. 



Compare the requirements of the Bearer Request 
from the Bearer Control functional layer in the previous 
"] network and the BearerRsvRequest from the Call Control 
^ functional Jayer ol [this terminal to ensure consistency. 



(FALSE) 



If bearer requests are consistent, then 
request that the Media Control functional 
layer of this terminal identifies the media 
options for the call. 



BearerRsv_ 
Reject 



Bearerldle 



Figure A.109: Terminating Terminal: Reserving a bearer: compare the requirements and reserve 

media 
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Reserving. 2 







\ N1 .Media_ 
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BearerRsv 
Confirm 





Report the bearer requirements and media 
i options for the call to the Call Control 
functional layer in this domain. 



Terminating_ 
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Reserved 



Figure A.110: Terminating Terminal: Reserving a bearer: confirm media reservation to call control 

layer 
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/ N1.MediaEst_ 
\ Request 







Terminating_ 

Bearer_ 
Establishing 



Report to the Media Control functional 
i layer in this functional grouping the 
chosen media options. 



Terminating_ 

Bearer_ 
Establishing 



> N1.MediaEst_ 
Confirm 



C1 .Bearer 

Confirm 

viaC1 



BearerEst_ 
Confirm 



Bearer_ 
Established 



Report the media is established to the 
Call Control functional layer of this terminal. 
The media stream may be one-way or 
two-way at this stage depending on 
implementation options. 

Note that the network may choose not to 
permit conveyance of two-way speech flows. 



Figure A.111: Terminating Terminal: Establishing a bearer 
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Figure A.112: Terminating Terminal: Activating a bearer 
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i functional layer in this functional 
grouping. 
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Confirms the bearer release to the Call 
i Control functional layer in this functional 
grouping. 
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Figure A.113: Terminating Terminal: Releasing a bearer 
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A.2.5.5 The Media Control functional layer 
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Figure A.114: Terminating Terminal: Reserving media 
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Requests that the IP Transport plane 
T1.TransportEst_ 'implements the media requirements. N1.MediaEst_ 
~] Requests that the IP Transport plane Confirm 
provides an adequate QoS, based on the 
QoS requirements for the call. 



Media_ 
Establishing 
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Media_ 
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Confirm establishment of the media 
connection to the Bearer Control 
^functional layer of this domain, two way 
communications may be available 
at this point. 



Figure A.115: Terminating Terminal: Establishing media 
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Figure A.116: Terminating Terminal: Activating media 
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>Release_ 
Confirm 



T1. Transport 

Release_ 
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Requests that the IP Transport plane 
] terminates the media flow 
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] Bearer Control functional layer 
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Figure A.117: Terminating Terminal: Releasing media 



A.2.5.6 The IP Transport plane 



The functional model and the functional entity actions of the IP Transport plane are outside the scope of the present 
document. 
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Annex B (informative): 

Backward compatibility with TS 101 313 

This annex shows the relationship between the architecture in the present document and the previous architecture given 
in the TS 101 313 [5]. 

Figure B.l shows the functions and reference points defined in TS 101 313 [5]. These functions are as follows: 

• GK is the gatekeeper and provides address translation and controls access to the network for terminals, 
gateways, etc.. 

• The Gateway is composed of three separate Functional Blocks: 

Media Gateway: Provides the media mapping and/or transcoding functions. 
Media Gateway Controller: Controls the Media Gateways. 
- Signalling Gateway: Provides the signalling mediation function between the IP domain and the SCN domain. 

• The H.323 terminal is an endpoint other than a gateway or a multipoint control unit. 

• Back end represents services provided by third parties. 




Figure B.1 : Functional groupings and reference points in TS 101 313 [5] 



ETSI 



123 



ETSI TS 101 314 V1.1.1 (2000-09) 



Figure B.2 takes the functions defined in TS 101 313 [5] and maps the reference points in the present document to those 
functions. The functions defined in TS 101 313 [5] can therefore be seen to contain entities in one or more of the 
functional layers defined in the present document. 




Figure B.2: The old functions and the new reference points 
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Annex C (informative): 

Example of an H.323 implementation 

This annex contains material that enabled the architecture in the main body of the present document to be compared 
with an example implementation. The information contained in this annex will be superseded by publications 
containing a more complete analysis. When that material is available, this annex will be removed. 

Figure C.l and figure C.2 show the elements as defined in ITU-T Recommendation H.323 (see Bibliography) and how 
the functional entities as described in the present document map to these entities. Please note that these figures show the 
relationships, not a topology. 




Figure C.1 : H.323 entities (1) 




Figure C.2: H.323 entities (2) 
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C.1 Terminal 

The terminal contain the following functional entities as defined in Clause 6: 

Services 

Ticket 

Service Control 

Registration (user part) 
Call Control 
Call control function. 
Bearer Control 
Bearer control 
Media Control 
Media control 



C.2 Gateway (GW) 

The gateway ensures the interworking between an IP network and an SCN network. It is composed of three separate 
Functional Blocks: 

• the Signalling Gateway; 

• the Media Gateway; 

• the Media Gateway Controller. 

C.2.1 Media Gateway 

Media Control 

C.2.2 Media Gateway Controller 

Service Control 

Routing (optional) 
Call Control 
Call Control 
Bearer Control: 

Bearer Control 
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C.2.3 Signalling Gateway 

Service Control 

Routing: (optional) 
Call Control 

Call Control 

Bearer Control: (optional) 
Bearer Control 
Management 

Network entity registration (Entity part) 



C.3 GateKeeper (GK) 

The gatekeeper Function shall be responsible for control and management of the various elements of the TIPHON 
Phase 2 reference configuration. The gatekeeper Function shall determine the route that call signalling and media 
transport takes for each call. It may contain the following functional blocks. 

Service Control 



Routing: 

User profile (optional) 
User profile access (optional) 
Registration (server part) 
Call Control (optional) 
Call Control 

Bearer Control: (optional) 
Bearer Control 



Many of these functions are optional. H.323 has made the definition of the Gatekeeper sufficiently broad that all of the 
implementations shown in figure C.3 may be considered as a legal implementation. The most minimal gatekeeper 
(number 5) only accepts registration and call routing requests. 
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Figure C.3: Legal H.323 gatekeeper implementation alternatives 
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C.4 Border Element (BE) 

The border element shall be responsible for the communication between (IP-based) networks. It may contain the 
following functional blocks. 

Service Control 

Call Control (optional) 

Bearer Control: (optional) 
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Annex D (informative): 
Example of a SIP implementation 

This annex contains material that enabled the architecture in the main body of the present document to be compared 
with an example implementation. The information contained in this annex will be superseded by publications 
containing a more complete analysis. When that material is available, this annex will be removed. 

The SIP technology includes two protocols of interest to TIPHON. 

• SIP - As defined in RFC 2543 (see Bibliography), this is often used as a client based call control protocol. 

• SIP BCP-T (also known as SIP+) - This is an application of SIP to ISDN/PSTN transparency. The ISUP being 
encapsulated with a MIME type. 

In order to define the example implementation, functional elements of each protocol are identified, and the functions 
within each element are described. 



D.1 The SIP architecture 



The SIP protocol has 5 functional elements defined in RFC 2543 (see Bibliography). 

• User agent client The user agent client is the functional entity that may initiate a SIP request. 

• User agent server The user agent server is the functional entity that may initiate a SIP response. 

• Proxy server This functional element is functionally similar to the user agent server, except it is not expected to 
retain significant call control state. In essence the proxy server is comprised of both a SIP client and a SIP server. 

• Redirect server The redirect server is not responsible for call control but will simply respond to SIP requests 
with a new address. 

• Registrar server The registrar server simply responds to registrar requests. Typically this is co-located with 
either the proxy or the redirect server, and may be adapted to perform location4oased services. 

The functional elements can be seen in the call flows in the diagrams below. 
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-► SIP request 
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Figure D.1 : Example of proxy server and user agent functional entity 
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Figure D.2: Example of redirect server functional entity 
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Figure D.3: Example of registrar server functionality 

Examining in more detail the nature of each of these functional elements: 



D.1 .1 User agent (User agent client and User agent server) 

User agents are the applications that generate and receive SIP messages, and these applications can either exist as the 
calling party (user agent client) or the called party (user agent server). The functionality of the user agents can be 
considered to be roughly equivalent to the composed H.323 gateway and the H.323 terminal. 

The user agent is responsible for service control, call control, bearer control and the media control layer. Taking the 
functional components in the existing document 02003 it is possible to derive the subset of functional elements that are 
included in each component. The functional elements that the user agent performs may include: 

• Service Control 



- Registration (User part) 
Ticket 



• Call Control 



- Call control 
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• Bearer Control: 

- Bearer control 

• Media Control 

- Bearer control 

D.1.2 Proxy server 

The proxy server is equivalent to the functional combination of a SIP server and SIP client. It may additionally perform 
some form of translation between these two functions for the purposes of security policy management. Its functional list 
is therefore a superset of the user agent functional element. The proxy server may include the following functions. In 
particular the proxy server is unlikely to exist at the bearer control layers and media control layers in the stateless proxy 
scenario. 

• Service Control 

- Routing: 
User profile 

- Name to Name translation 

- Name to address translation 

- Authentication 

• Call Control 

- Call control 

• Bearer Control (Optional in the stateless proxy case) 

Bearer Control 

• Media Control (Optional in the stateless proxy case) 

- Media Control 

D.1.3 Redirect server 

The redirect server is only responsible for redirecting a call to a different server, and is therefore not responsible for 
performing any of the bearer control and media control functions. The functional elements are included below. 

• Service Control 

- Call routing: 

- Name to Name translation 

- Name to address translation 
User profile 

• Call Control 

- Call Control 

D.1 .4 Registrar server 

The registrar function is responsible for users to register to a SIP server. It therefore will often be combined with a 
proxy or redirect server which is then responsible for providing the services required by the user, for example mobility. 
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The registrar server therefore contains only the registration functions of the TIPHON architecture. 
• Service Control 

- Registration (server part) 

- Authentication 

- User profile 

D.1 .5 The SIP functional elements mapped onto the TIPHON 
architecture 

Figure D.4 shows how the SIP functional elements map onto the Functional layers in the IP Telephony Application 
plane. 
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NOTE: The stateless proxy server must not exist in the Bearer Control functional layer or in the Media Control 
functional layer. 

Figure D.4: The SIP example mapped onto the IP Telephony Application plane 



D.2 The SIP-BCP-T architecture 

The SIP BCP-T protocol enhances SIP by the encapsulation of ISUP in the SIP protocol, with the ISUP identified by a 
MIME type, see RFC 2049 in Bibliography. The main call control function in SIP-BCP-T is referred to as an MGC. 
However it is clear that the SIP-BCP-T functional element is different from the MGC defined in ITU-T 
Recommendation H.323 since the SIP MGC must support all the call control. In ITU-T Recommendation H.323 the 
MGC may contain the Call control in the direct routed case but in the gatekeeper routed case the call control is shared 
by both the gatekeeper and the MGC. In order to distinguish between these two cases it is proposed to define the new 
functional component for the SIP MGC, known as the UA-MGC (User Agent Media Gateway Controller). 



D.2.1 The functional elements of the UA-MGC 

The UA-MGC is very similar to the user agent in the previous example, the addition of the ISUP only providing an 
additional method of call control rather than additional functions. The only distinction from the user agent in the SIP 
example is that it is not responsible for media control since that is the function of the media gateway. The functional 
elements included within the UA-MGC as taken from 02003 can be seen below. 

• Service Control 
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- Call routing: 

- Name to Name translation 

- Name to address translation 

- Authentication 

- User profile 

• Call Control 

- Call control 

• Bearer Control: 

- Bearer Control 

Figure D.5 shows how the SIP BCP-T functional element may be mapped onto the functional layers in the IP 
Telephony Application plane: 
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Figure D.5: The SIP-BCP-T functional elements mapped onto the IP Telephony Application plane 
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Annex E (informative): 

Example of an BICC implementation 

This annex contains material that enabled the architecture in the main body of the present document to be compared 
with an example implementation. The information contained in this annex will be superseded by publications 
containing a more complete analysis. When that material is available, this annex will be removed. 

The BICC (see Bibliography) protocol is an evolution of ISUP (see ITU-T Recommendations Q.763 and Q.764 in 
Bibliography) towards packet networks and is of relevance to TIPHON scenario 3. This annex describes the mapping of 
the BICC architecture to the TIPHON architecture. 



E.1 BICC architecture 



Figure E. 1 (lifted from BICC, see Bibliography) presents the architecture for the Bearer Independent Call Control 
protocol Capability Set 1 (BICC CS1). This architecture defines a number of functions that are explained below. 
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Figure E.1 : BICC architecture 

Definitions of the relevant items contained in the BICC CS 1 composite functional model are as follows (lifted from 
[2]). 

Bearer Control Function (BCF): Four types of BCF are defined; BCF-N, BCF-T, BCF-G and BCF-R. The BCF-N, 
BCF-T and BCF-G provide the control of the bearer switching function, the communication capability with its 
associated CSF, and the signalling capability necessary for the establishment and release of the bearer to its peer. The 
BCF-R provides the control of the bearer switching function and relays the bearer control signalling requests to next 
BCF in order to complete the end to end bearer control signalling action. 

Bearer InterWorking Function (BIWF): A functional entity which provides bearer control functions (BCF) and 
media mapping/switching functions within the scope of a Serving Node (SN). A BIWF contains one BCF. 

Call Mediation Node (CMN): A functional entity which provides CSF functionality without an associated BCF entity. 

Call Service Function (CSF): Four types of CSF are defined: 

• The Call Service Nodal Function (CSF-N) provides the service control nodal actions associated with the 

narrowband service by interworking with narrowband and bearer independent signalling, signalling to its peer 
CSF the characteristics of the call, and invoking the Bearer Control Nodal Functions (BCF-N) necessary to 
transport the narrow band bearer service across the backbone network. 
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• The Call Service Transit Function (CSF-T) provides the service transit actions necessary to establish and 
maintain a backbone network call (see Figure E.2), and its associated bearer by relaying signalling between CSF 
peers and invoking the Bearer Control Transit Functions (BCF-T) necessary to transport the narrowband bearer 
service across the backbone network. 

• The Call Service Gateway Function (CSF-G) provides the service gateway actions necessary to establish and 
maintain a backbone network call and its associated bearer by relaying signalling between CSF peers and 
invoking the Bearer Control Gateway Functions (BCF-G) necessary to transport the narrowband bearer service 
between backbone networks. 

• The Call Service Co-ordination Function (CSF-C) provides the call co-ordination and mediation actions 
necessary to establish and maintain a backbone network call by relaying signalling between CSF peers. The 
CSF-C has no association with any BCF. It is only a call control function. 

Gateway Serving Node (GSN): A functional entity which provides gateway functionality between two network 
domains. This functional entity contains the call service function (CSF-G), and one or more bearer interworking 
functions (BIWF). GSNs interact with other GSNs, in other backbone network domains and other ISNs and TSNs 
within its own backbone network domain. 

Interface Serving Node (ISN): A functional entity which provides the interface with SCNs. This functional entity 
contains the call service nodal function (CSF-N), and one or more bearer interworking functions (BIWF) which interact 
with the SCN and its peers within the backbone network. 

Switching Node (SWN): A functional entity which provides the switching functions within the backbone core 
network. This functional entity contains a BCF-R. SWNs interact with other SWNs and BIWFs, within their own 
backbone network domain. 

Switched Circuit Network (SCN): generic term for any network that uses circuit switching technology, i.e. ISDN, 
PSTN, PLMN... 

Transit Serving Node (TSN): A functional entity which provides transit functionality between two SNs. This 
functional entity contains the call service function (CSF-T), and supports one or more bearer interworking functions 
(BIWF). TSNs interact with other TSNs, GSNs and ISNs within their own backbone network domain. 



E.2 Mapping between BICC and TIPHON 

From the above it is clear that BICC has slightly different terminology from TIPHON. 

BICC CS 1 is a signalling protocol that supports narrow band PSTN/ISDN services transparently over packet networks. 
BICC as call control protocol is designed to be independent of the medium (i.e. bi-directional voice stream or data 
stream) and its encoding (g.71 1, or unrestricted). 

The carrier is separated out (ATM AAL1, ATM AAL2 and IP in BICC CS2). This implies that while in TIPHON the 
bearer is the abstract representation of the media flow, in BICC the term is used for the physical representation. 

The BICC call control signalling conveys both call set-up and media parameters and would therefore map to the 
TIPHON call and bearer information flows. BICC conveys (transports) parameters related to the characteristics of the 
bearer. 

The BICC SWN nodes are ATM switches or IP routers (for BICC CS2). So they would fall in the TIPHON transport 
plane and hence be outside the scope of the present document. Communication to these SWN entities is in BICC 
regarded as bearer communication. A BICC bearer information flow is generally implemented using a subset of UNI 
4.0 and hence corresponds to a TIPHON application to transport flow. 

The BICC BIWF has 2 major groups of functionality: 

• signal the establishment of the transport channel (BCF) 

• send media over that channel (for that there is RTP over UDP/IP rather than ATM AAL1 or ATM AAL2)) 

So because of its different focus the corresponding TIPHON function is called MC for media control. That function also 
harbours media transcoding and media servers. 
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From this knowledge a TIPHON view of the mapping of the layers between the two architectures follows: 
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Figure E.2: TIPHON - BICC mapping 
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Annex F (informative): 
Intelligent Network (IN) 

This annex contains material that enabled the architecture in the main body of the present document to be compared 
with an example implementation. The information contained in this annex will be superseded by publications 
containing a more complete analysis. When that material is available, this annex will be removed. 



F.O Scope 

This annex describes the mapping of the TIPHON IP Telephony Application planes to IN functions. This annex 
illustrates how the existing Intelligent Network components can be leveraged by components within the TIPHON 
architecture. This mapping can be used in deployments, which could then utilize it as an efficient and effective service 
control layer implementation. 



F.1 Introduction to the Intelligent Network 

The Intelligent Network is a beneficial switch dis -aggregation model that is designed to conform to a layered 
architecture. It serves to effectively distinguish between call control- and service control- related functions in the 
telecommunications network. 

The IN conceptual model consists of four planes: 

• the services plane, 

• the global functional plane, 

• the distributed functional plane, 

• the physical plane. 

For a description of the details of this architectural framework, the interested reader is referred to [1] and [2]. 
A summary of functions of elements from the Distributed Functional Plane (DFP) is as listed below ([2] and [3]): 
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CCAF 


The CCAF is the call control agent (CCA) function that provides access for users. It is the 
interface between user and network call control functions 


CCF 


The CCF is the call control (CC) function in the network that provides call/connection 
processing and control. 


SSF 


The SSF is the service switching (SS) function, which, associated with the CCF, provides 
the set of functions required for interaction between the CCF and a service control function 
(SCF). 


SCF 


The SCF is a function that commands call control functions in the processing of IN 
provided and/or custom service requests. The SCF may interact with other functional 
entities to access additional logic or to obtain information (service or user data) required to 
process a call/service logic instance. 


SDF 


The SDF contains customer and network data for real time access by the SCF in the 
execution of IN provided service. 


SRF 


The SRF provides the specialized resources required for the execution of IN provided 
services (e.g. digit receivers, announcements, conference bridges, etc.) 


SCEF 


Service Creation Environment Function. This function allows services provided in an 
intelligent network to be defined, developed, tested and input to SMF. Output of this 
function would include service logic, service management logic, service data template and 
service trigger information. 


SMAF 


Service Management Access Function. This function provides an interface between service 
managers and the SMF 


SMF 


Service Management Function. This function allows the deployment and provisioning of IN 

■II 1 III i 1 ■ f a . ■ 

provided services and allows the support of ongoing operation. 


CUSF 


The CUSF is the call unrelated service (CUS) function, which, associated with the CCF and 
SSF, provides a set of call-unrelated service functions required for out-channel interaction 
with a SCUAF. It also provides the set of functions required for interaction between the 
SCUAF and a SCF. 


SCUAF 


The SCUAF is the Service Control User Agent (SCUA) function that proves access for 
users. It is the interface between a user and the Call Unrelated Service Function (CUSF). 



In the physical plane, one maps DFP entities to their corresponding physical components. For example, in traditional 
PSTN networks, the SSP (Service Switching Point) embodies the SSF and CCF functions, while the SCP (Service 
Control Point) is a physical manifestation of the SCF and optionally, the SDF functions. 



F.2 Mapping Functional Elements onto the TIPHON 
Reference Architecture 

Figure F. 1 depicts a mapping of these IN functional elements to the TIPHON architecture. 
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Figure F.1 : Mapping of IN functions onto TIPHON functional Architecture 

The mapping of most of the functions is straightforward and described in Table F. 1 . 

Table F.1 : Mapping of IN functions to TIPHON architecture 



IN function 


TIPHON layer 


TIPHON Function 


SDF 


Services Layer 


Stores registration, user-related, service-related, and routing 
information in a format that supports real-time retrieval. 


SCF 


Services layer 


Hosts IN services (e.g., LNP, OCS, CNIP, Pre-paid etc.,) 
accessible to both PSTN and IP end-points. 


CCF 


Call Control Layer 


Supports the IN call model that tracks "service network" view 
of call state from the base (packet network) network. 


SSF 


Call Control Layer 


Provides the call control element the ability to access IN 
services. 


SCEF, SMF and 
SMAF 


Management Plane 


SCEF supports the creation/authoring of new services in the 
services network. The SMF that is mainly concerned with 
managing and provisioning services in the IN network, and 
the SMAF that provides access for such management tasks 
should be more closely tied in with the rest of the 
management framework. 


SRF 


Media Control Layer 


Play announcement/ collect digits capabilities as directed by 
entities in the SC layer 


SRF 


Bearer Control Layer 
(optional) (note) 


Temporary connections may be set up to the SRF entity. 


NOTE: The announcement and digit collection capabilities of the SRF clearly locate this function into the 
Media control layer of the IP Telephony Application Plane. However, the potential ability of the SRF 
to manage bearers connections, leads to an extension into the Bearer Control functional layer. 



The mapping of following IN functions is for further study: CCAF (Call Control Agent Function), and additional 
functions defined in ITU-T Recommendation Q.1224 [3] (CUSF - the Call Unrelated User Function, and CUASF - the 
Service Control User Agent Function). 
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F.3 



Interaction Scenarios: 



The following interaction Scenarios can be distinguished. This clause gives two examples for IN interworking 
Scenarios: 

• basic calls; and 

• additional services from the IN services network. 
These interaction Scenarios may be of two types: 

• IN controls SCN calls but also assists the TIPHON network 

This, by definition requires a call flow that traverses multiple networks. If one end-point involved in the call is 
an SCN end-point and the other is an IP end-point, then IN components could serve the SCF and SDF functions 
for the SCN end-point and may simultaneously, if so enabled, support access to IN services from the IP end- 
point. If, on the other hand, both were SCN end-points but the connection traverses an IP network, and IN 
services were accessed from that intermediate network, the same technique may be used again. In the latter case, 
IN services may be accessed at either end, or from the IP network component capable of IN service access. 

• IN also controls the TIPHON network 

The SSF for the IN network may be co-located with the CCF for the base (IP) network, thus permitting the base 
network element to access services from the IN service network. 



The following Scenarios serve to illustrate how IN-supported services are made accessible to end-points located within 
the confines of a packet network. In most cases, the call flows as depicted in the main body of the TIPHON architecture 
document are general enough to depict such service access. 



Consider the case where the user at an IP terminal originates a call by dialling in an E.164 [1] number for a destination. 
This number may need to undergo an LNP translation before it is routed to an other network (gateway) and from there, 
out into the other network to reach correct end-point. For purposes of this scenario, consider that the LNP service is 
accessed while still in the packet network context, so that the routing function could use this information to determine 
the optimal gateway to route out to. 

The information flows are identical to those depicted in Clause 8 for the various scenarios, only, now the IN network 
hosts the service control function, (i.e., the flows for "Access & Routing Request" and "Service Request" now 
transparently serve the purpose of accessing IN services as required). 



A user at an IP terminal originates a call and the call server within the IP network generates a query to an SCP that 
verifies that the dialled number is on a list of allowed destinations, and responds accordingly (alternatively, the SCP 
could verify that the dialled number is not on a list of dis-allowed destinations). The call server parses the response and 
either route the call, or drops it, based on the SCP generated response. 

This is an example of "Routing/ Access Request" made by call control to service control on the originating side of the 
call. This is already reflected in the information flows shown. 



F.4 Example Scenarios 



F.4.1 Local Number Portability (LNP) 



F.4.2 Originating Call Screening (OCS) 
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F.5 Call Model Integration: 

In this clause, a means is described by which IP-based call control elements may be enabled to access services from 
the IN network. It must be emphasized here that this technique serves merely as an illustration of a means to achieve 
said inter- working between the IP and IN networks, and is by no means the only way to achieve the desired results. 

Services hosted off of the Intelligent Network (IN) are advantageously accessed during call processing by IN-aware 
PSTN switches or SSPs to significantly enhance the user experience in that network. 



PSTN Network 




(e.g. H.323, SIP) Media Gateway 

Media Gateway Controller 

Figure F.2: Overall Architecture 

Along similar lines, IP users could also benefit from services in the IN network if a means existed to permit IN service 
access from IP endpoints. In this clause, a means is described for doing this by integrating the IN call model with the 
Call Processing Finite State Machine (FSM) on the IP-based platform. This process is called "Call Model Integration" 
(CMI)[4]. 

CMI essentially serves as an inter- working function between the existing call control function for the network end- 
points governed by a packet multimedia conferencing protocol and the call control/service switching function for the IN 
network that is viewed as the services functional layer. This enables seamless access to IN-supported services from IP 
end-points. 

Call Model Integration achieves this by overlaying an IN call model implementation atop the base call model FSM (the 
call control state machine in the IP network), with the two state machines operating in lock step. Now, state changes in 
one FSM are accompanied by the corresponding state changes in the other (so there is a unified view of call-states 
across networks - the IP-base network and the IN services network). 

This is accomplished through the generation of a semantic map between the FSM supported for call control within the 
gatekeeper or other base network call control element, and the IN-based BCSM that is analogous to the one that is 
supported within a traditional SSP (Service Switching Point). One thus has a unified view of call control that takes into 
account the call state information pertaining to the call in each network. 

The protocol for communication between the SSF function hosted within the context of the base packet network and the 
SCF function within the IN may be either INAP/IP (if this is a direct connection), or INAP/SS7 if the communication 
traverses an IWF (signalling gateway). 
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F.6 Future extensions 

Scenarios that address advanced IN service capabilities such as those pertaining to the firing of mid-call triggers, or 
access to Intelligent Peripheral functions (the Specialized Resource Function or SRF in the IP network) are for further 
study. 

Please also note that the IN services covered in the examples tend mostly to impact call control messages in the IP 
network (i.e. the IN response is used to modify call control messages as required, so that call setup is affected 
appropriately). 

Some other services may require modifications to connection control messages in the IP network, and these are for 
further study. Examples of the latter case include scenarios where call setup requires that a temporary leg be set up to a 
media server (for instance), and then that this leg be disconnected and a new call leg set up to another called party. This 
is the case with credit card calls. A caller dials a toll-free number, is presented with an IVR - mainly to authenticate the 
caller, and asked to dial a destination address. Once the dialled digits for this destination address are collected, the 
Specialized Resource Function may no longer be involved in the call, and another call leg to the actual called party is 
established. 
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